[PHP/(My)SQL] voor dummies - Deel 64

Vraagje, ik declareer een array in mijn class:



Vervolgens heb ik een functie waarmee ik deze array wil vullen:



Hier moeten twee matches uitkomen.

Wanneer ik nu de functie ga aanroepen en de array ga weergeven, krijg ik de volgende zooi terug:



Terwijl wanneer ik het op een simpele manier test de array wel gevuld is, iemand een idee? :)

Waarom noem je $matches in je voorbeeld?

Thanks Glowmouse, maar het bleek in de access modifier van een andere variabel te zitten

Kan je een "SELECT * " SQL uitvoeren waarbij je 1 kolom exclude uit de resultaten?

quote:

Op donderdag 6 november 2008 15:18 schreef ursel het volgende:
Kan je een "SELECT * " SQL uitvoeren waarbij je 1 kolom exclude uit de resultaten?

Waarom niet gewoon dan SELECT veld1, veld2, veld3 FROM table doen?

Ik heb nog niet zo heel veel met SQL gewerkt ofzo, maar je kunt toch gewoon de gegevens uit die kolom dan niet gebruiken?

Maar de manier van JortK lijkt me idd beter, dat zal een (iets) minder zware query zijn.

quote:

Op donderdag 6 november 2008 15:28 schreef JortK het volgende:

[..]

Waarom niet gewoon dan SELECT veld1, veld2, veld3 FROM table doen?

Ik ben momenteel bezig om van ons archive-proces deze ook te gebruiken om producten te kunnen klonen.
Bij het archiveren heb ik geen last van DUPLICATE KEYS omdat deze keys nog niet in de archive database zitten.

Tijdens het kloon process blijf ik dus in dezelfde database en moet eigenlijk alleen sommige ID's gebruik gaan maken van de auto-incremental.

Het product te klonen heeft informatie in +/- 10 tables, waarbij de main-table zelfs tot 35 kolommen bevat. Ik hoopte dus eigenlijk dat ik grote delen van het archive proces kon hergebruiken..

Het is sowieso netter om geen "SELECT *" te gebruiken.

quote:

Op donderdag 6 november 2008 15:32 schreef Tijn het volgende:
Het is sowieso netter om geen "SELECT *" te gebruiken.

Afhankelijk van je doel.
Voor het archiveren gebruiken we nu dus de query

INSERT INTO targetDB.table SELECT * FROM sourceDB.table WHERE ID = X

quote:

Op donderdag 6 november 2008 15:32 schreef Tijn het volgende:
Het is sowieso netter om geen "SELECT *" te gebruiken.

Want? Het is netter om 10 kolommen op te sommen wanneer je 10 kolommen hebt, i.p.v. *? Says who?

quote:

Op donderdag 6 november 2008 16:11 schreef CraZaay het volgende:

[..]

Want? Het is netter om 10 kolommen op te sommen wanneer je 10 kolommen hebt, i.p.v. *? Says who?

Tis eerder dat je de order kan garanderen als je niet * gebruikt, maar elk veld apart definieert. Anders kan het zijn dat iemand een table wijzigt en de order daarmee wijzigt, je app breekt omdat ie X verwacht daar waar hij Y krijgt.

Tenminste, dat is het argument wat ik gelezen heb hierover. Zie bijvoorbeeld hier: http://dbaforums.org/oracle/index.php?showtopic=8443

quote:

Op donderdag 6 november 2008 17:10 schreef slacker_nl het volgende:

Tis eerder dat je de order kan garanderen als je niet * gebruikt, maar elk veld apart definieert. Anders kan het zijn dat iemand een table wijzigt en de order daarmee wijzigt, je app breekt omdat ie X verwacht daar waar hij Y krijgt.

Ik ken het hele concept van "breekbare order" niet, leg uit? Daarnaast lijkt het me niet eenvoudig om met een select iets te wijzigen in een tabel

Het zal eerder over een INSERT gaan, waarbij je niet je veldnamen specificeert.

quote:

Op donderdag 6 november 2008 19:03 schreef CraZaay het volgende:
Ik ken het hele concept van "breekbare order" niet, leg uit? Daarnaast lijkt het me niet eenvoudig om met een select iets te wijzigen in een tabel

De orde is de volgorde, bij * is de volgorde zoals de table is aangemaakt, als ik vervolgens twee alters op een table uitvoer waarbij de orde van de velden veranderd, bijv:

create table blaat ( id int, val varchar(10), val2 varchar(10));

De volgorde is id, val, val2. Als ik nou val2 naar val rename en val naar val2 dan wordt de volgorde:
id, val2, val

Logisch, maar als ik dan een applicatie heb die select * from blaat uitvoert en bij val altijd koe of paard terugkrijgt (om maar een willekeurig iets te zeggen), maar nu omdat het val2 is, wordt dit boer of boerin. M'n applicatie verwacht dit niet, dan breek ik de applicatie (en niet de database uiteraard!). Als je checks op de data uitvoert zullen die checks failen, omdat je impliciet uitgaat van een bepaalde volgorde. Als je dit expliciet aangeeft in je query heb je dit hele probleem niet.

Nu kan je natuurlijk ook de zooi dmv een hash terugkrijgen, waardoor het niet echt veel uitmaakt, maar dit is wel degelijk van belang bij een sequentiele array.

In het kort, als je SELECT * uitvoert, laat je de DB bepalen wat de volgorde is, als je de velden zelf definieert bepaal je het zelf en heb je in theorie minder wijzigingen in je code als je wijzigingen in je DB maakt.

Hoop dat dit e.e.a. duidelijker maakt. Je hoeft het er niet mee eens te zijn, ik ben er voor mezelf ook nog niet uit of SELECT * nou echt zo'n zonde is als men zegt.. Maar goed, als iemand wat wijzigt in de DB en je hebt het expliciet de volgorde aangegeven dan weet je zeker dat er niks fout gaat en anders moet je hopen dat men de volgorde niet heeft aangepast....

@slacker_nl:
Je hebt inderdaad een goed punt. Sowieso is het fijner om de output van de DB zelf in "controle" te hebben door zelf de volgorde aan te geven.

Slacker_nl heeft een goed punt, hoewel dit ook weer een nadeel is.

Ik moet vaak (Excel) exports vanuit een tabel maken, waar in principe alle data in terecht komt. Bij wijzigingen in de tabel is het wel prettig om dan * te dumpen, in plaats van dat je alle wijzigingen in de db ook in je exportcode moet gaan doorvoeren

hallo

ik probeer de inhoud van een bestand in mijn database te krijgen en gebruik hiervoor deze code:


ik krijg telkens

quote:

File kan niet worden geopend.

wat doe ik verkeerd?

Wat geeft var_dump( $lines )?

bool(false)

quote:

Op donderdag 6 november 2008 21:05 schreef rulerofdeath het volgende:
hallo

ik probeer de inhoud van een bestand in mijn database te krijgen en gebruik hiervoor deze code:
[ code verwijderd ]

ik krijg telkens
[..]

wat doe ik verkeerd?

Waarschijnlijk ondersteunt gzfile() het http://-protocol niet.

ik krijg nu een andere melding, ik zit nu ook bij een andere provider:

Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 1048576 bytes) in /var/www/vhosts/biertafel.eu/httpdocs/index.php on line 1

(lijnnummer aangepast aan codefragment)

quote:

Op donderdag 6 november 2008 20:01 schreef slacker_nl het volgende:

De volgorde is id, val, val2. Als ik nou val2 naar val rename en val naar val2 dan wordt de volgorde:
id, val2, val

Logisch, maar als ik dan een applicatie heb die select * from blaat uitvoert en bij val altijd koe of paard terugkrijgt (om maar een willekeurig iets te zeggen), maar nu omdat het val2 is, wordt dit boer of boerin. M'n applicatie verwacht dit niet, dan breek ik de applicatie (en niet de database uiteraard!). Als je checks op de data uitvoert zullen die checks failen, omdat je impliciet uitgaat van een bepaalde volgorde. Als je dit expliciet aangeeft in je query heb je dit hele probleem niet.

Als je expliciet aangeeft dat je "SELECT val FROM ..." wilt, en deze kolom bevat opeens de data die voorheen bekend was als val2, dan heb je toch alsnog hetzelfde probleem, of begrijp ik je verkeerd?

quote:

Op donderdag 6 november 2008 21:48 schreef rulerofdeath het volgende:
ik krijg nu een andere melding, ik zit nu ook bij een andere provider:

Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 1048576 bytes) in /var/www/vhosts/biertafel.eu/httpdocs/index.php on line 1

(lijnnummer aangepast aan codefragment)

De melding zegt het al, je systeem/profiel heeft te weinig geheugen voor deze opdracht. Of je moet meer geheugen aanvragen of je moet je script op een andere manier gaan realiseren (bv via commandline de zip file extracten en dan rustig aan inlezen)

quote:

Op donderdag 6 november 2008 21:53 schreef CraZaay het volgende:

[..]

Als je expliciet aangeeft dat je "SELECT val FROM ..." wilt, en deze kolom bevat opeens de data die voorheen bekend was als val2, dan heb je toch alsnog hetzelfde probleem, of begrijp ik je verkeerd?

Je begrijpt me verkeerd, stel... iemand dumpt de database, maakt wijzigingen in de dump, dropped de originele table en creeert opnieuw de table, alleen zijn val en val2 van volgorde gewijzigd. Bij select * is de volgorde van val en val2 dus anders dan jij in eerste instantie verwacht.. Als je select val, val2 gebruikt veranderd er niks, en heb je dus ook geen problemen met deze wijziging..

Dit is de kern van het verhaal:

1) select veld, veld2, veld3: expliciet aangeven in welke volgorde (de keuze wordt gemaakt door jou).
2) select *: impliciet aangeven in welke volgorde (de keuze wordt gemaakt door de DB)

Welke je prefereert, of toepast, dat maakt mij weinig uit, maar je moet rekening houden dat je met select * onverwachte dingen kunt tegenkomen als men een wijziging uitvoert op de database. That is all.

Ik begrijp dus eigenlijk dat het niet mogelijk is om een kolom te excluden??

@slacker, Maar als je nou een associative array fetched?? Dan maakt dit toch ook niet uit? Of zie ik iets over het hoofd?