[MYSQL] 150 kolommen of 2 kolommen?

[whoami]

Verwijderd schreef op 21 juni 2004 @ 15:38:
Het oude datamodel is makkelijk, het is 1 tabel met kolommen:
id (primary key) van type int
+ 150 kolommen van type varchar(255)

Het nieuwe snellere datamodel is nog makkelijker:
id (prim key) type int
1 kolom textstrings van type text

1.
select * from tabel where id=7

2.
select textstrings from tabel where id=7
explode()

2. is een sneller dan 1., wat inhoud zoals gezegd dat hack sneller is dan mysql. Het is gewoon een feit.

Het datamodel wat drm voorstelt is mooier maar vrijwel zeker langzamer dan 2.

Aargh, ik ben blij dat ik niet met jou hoef samen te werken....

[dusty]

Kogels: Zoals ik jouw stelling lees, kan jij beter met files gaan werken, in plaats van met een database. Aangezien jij de bel wel hebt horen luiden, maar nog niet eens een flauw idee hebt waar de klepel is (of zelfs waarvoor het dient).

Als je een database gaat misbruiken als een flatfile systeem, kan je gewoonweg beter meteen met een filesysteem werken en de database achterwege laten.

[RwD]

Tis misschien een loze opmerking, maar waarom moet het zo snel?

Als je veel gebruikers verwacht, dan is mySQL sowieso niet de database voor jou...
En aan mijn kant van het internet merk ik een tiende van een seconde niet eens

Maar goed, als je nou eens uitlegd wat je doel is, en waarom die performance zo belangrijk is, misschien komt dan wel iemand met de gouden tip

bovendien heeft dusty 100% gelijk, dat scheelt je 1 hele query!!

[ Voor 9% gewijzigd door RwD op 21-06-2004 16:24 ]

[Verwijderd]

Verwijderd schreef op 21 juni 2004 @ 16:18:
Het gaat erom dat jij in je eerste datamodel uitging van een model met 150 kolomen. Die zou jij dan dus volgens het idee van DRM moeten uitsplisten in meerdere kolomen. Dan behaal jij een prima performance die absoluut jouw load aan kan die jij gaat verwachten... Dat weet ik zeker

Lees m'n orginele bericht nog maar eens goed door: "Het script heeft alle waarden in alle kolommen nodig". Wat zou sneller zijn: 1 record returnen of 150?

Daarnaast heb je een schaalbaar model; geef me de nadelen

Aargh lees m'n replies maar eens door (whoami en dusty ook )

Flatfile is hoogstwaarschijnlijk langzamer. Bovendien m'n script heeft al connectie naar db als ik de bovenstaande query uitvoer, de overhead van het connecten heb ik dus al achter mij liggen.

[Verwijderd]

RwD schreef op 21 juni 2004 @ 16:23:
Als je veel gebruikers verwacht, dan is mySQL sowieso niet de database voor jou...

Als ik de keus had had ik het gewoon in C gedaan, maar je moet de systeembeheerders is horen als je een c programmatje wil installeren

[curry684]

Verwijderd schreef op 21 juni 2004 @ 16:31:
[...]

Flatfile is hoogstwaarschijnlijk langzamer. Bovendien m'n script heeft al connectie naar db als ik de bovenstaande query uitvoer, de overhead van het connecten heb ik dus al achter mij liggen.

Waar dacht dat je mySQL z'n data laat?

Als je toch geen relationele of indexing eigenschappen gebruikt is een file per definitie tientallen tot honderden malen sneller dan een database.

[whoami]

Verwijderd schreef op 21 juni 2004 @ 16:31:
[...]


Aargh lees m'n replies maar eens door (whoami en dusty ook )

Ik durf wedden dat dusty en ik meer ervaring hebben met DBMS'en, en dus ook wel weten waar er performance winst te behalen is.
Heb je eigenlijk al eens gebenchmarked met een model zoals drm voorsteld?

Flatfile is hoogstwaarschijnlijk langzamer. Bovendien m'n script heeft al connectie naar db als ik de bovenstaande query uitvoer, de overhead van het connecten heb ik dus al achter mij liggen.

Dat denk ik niet, want zoals jij de DB nu gebruikt, creeër je gewoon overhead. Je gebruikt geen enkele van de features die een DB je biedt.

[Verwijderd]

Ik mag hopen dat mysql gebruik maakt van een cache en niet elke keer alle tabellen uit het bestandssysteem leest Bovendien kleven er ook andere nadelen aan: locken van bestanden, limieten mbt filehandlers, enzovoorts.

[dusty]

hoogst waarschijnlijk?

Dus je weet het nog niet eens zeker?

Maar het ophalen van de index, de ophalen van de rijen moet ook gebeuren door de database, de database haalt dat ook uit een file hoor!

Nee, dat je de extra overhead van het aanleggen van de connectie niet nodig hebt verlost dat helemaal niet.

Jij begrijpt de essentie van een database gewoonweg niet.

Wat zou sneller zijn: 1 record returnen of 150?

1 record returnen van 150 kolommen? of 150 records met 3 kolommen, waarvan 2 integers zijn.. IK ga voor de tweede optie, 150 record returnen met 3 kolommen is sneller bij een goede database, Het is beter te onderhouden, de integriteit is beter te garanderen.

Je wilt niet luisteren naar advies, echter wil je toch je 150 kolommen behouden, of dus alles serializen, gebruik dan gewoon een flatfile dat is gegarandeerd sneller.

[Verwijderd]

whoami schreef op 21 juni 2004 @ 16:37:
[...]

Ik durf wedden dat dusty en ik meer ervaring hebben met DBMS'en, en dus ook wel weten waar er performance winst te behalen is.
Heb je eigenlijk al eens gebenchmarked met een model zoals drm voorsteld?

Ach, laten we het niet op persoonlijk vlak gooien..

Waarom zou drm's model sneller zijn dan 1 simpele select statement die precies 1 record returnt? Als je dat kan uitleggen wil ik best drm's model is uitproberen.

[dusty]

Verwijderd schreef op 21 juni 2004 @ 16:38:
Bovendien kleven er ook andere nadelen aan:

Ha!, nu wordt het leuk!

locken van bestanden,

Locken van tables is er ook hoor, dat maakt verder geen donder uit immers gaat het hier over informatie ophalen, niet over het updaten of toevoegen. Immers was de onderhoudbaarheid geen probleem voor jou.

Je zegt hier in principe dat een peer beter is als een appel want een appel is een fruit.

limieten mbt filehandlers

En jij hebt geen limiet met het aantal connecties naar je database?

enzovoorts.

Geef die enzovoorts eens.. Ik wil namelijk nu wel eens weten hoever jouw kennis over databases gaat.

[Verwijderd]

dusty schreef op 21 juni 2004 @ 16:39:
Je wilt niet luisteren naar advies, echter wil je toch je 150 kolommen behouden, of dus alles serializen, gebruik dan gewoon een flatfile dat is gegarandeerd sneller.

Zou je m'n replies eens door kunnen lezen? Als je dat gedaan had had je kunnen weten dat m'n optimalisatie maar 1 record met 2 kolommen returnt ipv 1 record met 150 kolommen.

[curry684]

Verwijderd schreef op 21 juni 2004 @ 16:38:
Ik mag hopen dat mysql gebruik maakt van een cache en niet elke keer alle tabellen uit het bestandssysteem leest Bovendien kleven er ook andere nadelen aan: locken van bestanden, limieten mbt filehandlers, enzovoorts.

Filesystems cachen ook, en gaan ook slim om met file locking. Ze doen het alleen op een lager (en dus sneller) niveau dan de database.

Ik begin dit topic eigenlijk wel een beetje zat te worden: je stelt een vraag over performance, waarop heel veel mensen met heel veel verstand van zaken je een hoop vertellen daarover, maar je blijft koppig volhouden dat je gelijk hebt.

Heb je wel eens de profielen opengeklikt van de mensen in deze thread wat ze bij 'Beroep' ingevuld hebben staan?

[drm]

Laten we ondanks de hevige discussie wel even voorkomen dat 't persoonlijk wordt, heren

[dusty]

Verwijderd schreef op 21 juni 2004 @ 16:45:
[...]
Zou je m'n replies eens door kunnen lezen? Als je dat gedaan had had je kunnen weten dat m'n optimalisatie maar 1 record met 2 kolommen returnt ipv 1 record met 150 kolommen.

Ja, dus je optimalisatie haalt de overhead van de kolom namen en interne id's weg, echter zet je daarvoor weer een extra vertraging in waar een taal de string uit elkaar moet gaan halen.

[Verwijderd]

dusty schreef op 21 juni 2004 @ 16:43:

Locken van tables is er ook hoor, dat maakt verder geen donder uit immers gaat het hier over informatie ophalen, niet over het updaten of toevoegen. Immers was de onderhoudbaarheid geen probleem voor jou.

Lees m'n replies dan eens, je reactie is nu een beetje vreemd. Er is een formulier dat de eindgebruiker gebruikt om de waarden in die 150 kolommen te veranderen. Locken is dus wel nodig.

En jij hebt geen limiet met het aantal connecties naar je database?

4096, ik dacht dat filehandles op 250 stond.

[curry684]

Als we het trouwens over locks hebben: bij dermate brede tabellen escaleert een row lock linea recta naar een table lock zodra je aan het updaten gaat, omdat een page lock dan al niet meer past. Sgoed voor je performance

Gelukkig kent MySQL geen row-locks, en zal die dus meteen een table lock tevoorschijn trekken waarschijnlijk

[Verwijderd]

dusty schreef op 21 juni 2004 @ 16:48:
[...]

Ja, dus je optimalisatie haalt de overhead van de kolom namen en interne id's weg, echter zet je daarvoor weer een extra vertraging in waar een taal de string uit elkaar moet gaan halen.

We komen er wel (zoals beschreven in m'n replies) explode schijnt sneller te zijn dan de overhead van kolomnamen.

[Verwijderd]

De manier waarop je er nu mee omgaat kan gewoon niet; je bouwt sowieso te veel risico in met je 'slim' bedachte manier van het opslaan van 75 atttributes in 1 attribuut.... Nu moet je gaan afvangendat niemand een | invoert; anders gaat je hele zaakie onderuit; iemand gaat in de db hacken en wijzigd daar iets waardoor je hele array die je uit je explode haalt niet meer klopt oftewel: dit kan je gewoon niet doen!!!

Ik heb overigens nog steeds geen benchmark gezien die je explode ideetje goed maakt tegenover een correct databasemodel

[curry684]

Verwijderd schreef op 21 juni 2004 @ 16:50:
[...]

Lees m'n replies dan eens, je reactie is nu een beetje vreemd. Er is een formulier dat de eindgebruiker gebruikt om de waarden in die 150 kolommen te veranderen. Locken is dus wel nodig.

Zowel je filesystem als je database locken enkel met een Shared lock. Zodra er een update tussendoor komt zal deze een Intent Exclusive lock plaatsen om alle shared readers uit te pushen, maar de reads zijn wel degelijk simultaan. Ik vertrouw een gerenommeerd FS als ext2/3 of NTFS echter meer wat betreft dynamic lock promotion e.d. dan MySQL wederom

4096, ik dacht dat filehandles op 250 stond.

De meeste MySQL connecties onder Linux lopen via TCP, waarvan de sockets equivalent zijn aan filedescriptors en dus uit dezelfde process pool komen. Onder Win32 zijn zowel sockets als filehandles resource-limited.

[Verwijderd]

curry684 schreef op 21 juni 2004 @ 16:45:
[...]
Ik begin dit topic eigenlijk wel een beetje zat te worden: je stelt een vraag over performance, waarop heel veel mensen met heel veel verstand van zaken je een hoop vertellen daarover, maar je blijft koppig volhouden dat je gelijk hebt.

Heb je wel eens de profielen opengeklikt van de mensen in deze thread wat ze bij 'Beroep' ingevuld hebben staan?

Het word hier nogal gauw persoonlijk?

Het is een feit dat ik gelijk heb, de benchmark geeft mij gewoon gelijk (zie mijn eerdere replies).

[dusty]

mm.. ff een quote uit jouw start:

en haalt oa. 1 record uit een tabel

Je gaat over het algemeen vaker informatie uit een tabel halen, dan muteren. ( althans dat neem ik aan) jij zegt dat de eind gebruiker de waardes mag gaan muteren, hoeveel eindgebruikers krijg je die allemaal tegelijk de tabel gaan muteren, hoe zorg jij ervoor dat de juiste mutatie erdoor heen komt? Hoe lost jij je concurrency probleem op met het veranderen van de waarden door meerdere personen tegelijkertijd?

4096 [...] 250

Als je de standaard limiet van filehandles gebruikt, gebruik dan ook de standaard limiet van MySQL.

[curry684]

Verwijderd schreef op 21 juni 2004 @ 16:56:
[...]

Het is een feit dat ik gelijk heb, de benchmark geeft mij gewoon gelijk

Open dan geen topic waarin je om suggesties vraagt als je ze toch niet wil lezen.

[Verwijderd]

curry684 schreef op 21 juni 2004 @ 16:55:
De meeste MySQL connecties onder Linux lopen via TCP, waarvan de sockets equivalent zijn aan filedescriptors en dus uit dezelfde process pool komen. Onder Win32 zijn zowel sockets als filehandles resource-limited.

Mmm, dan zit ik op een vreemd systeem Vroeger had ik alles textfile based en toen begon de systeem beheerder te gillen dat dat toch niet meer ging. Toen had ik alles overgezet naar mysql en toen was hij helemaal tevreden. Kan het zijn dat de beheerder meer controleren heeft over sockets van mysql dan een filehandler die met bijvoorbeeld fopen word aangemaakt?

[dusty]

Verwijderd schreef op 21 juni 2004 @ 16:53:
[...]
We komen er wel (zoals beschreven in m'n replies) explode schijnt sneller te zijn dan de overhead van kolomnamen.

Jouw methode 2 is beter dan onze methode 3 omdat jouw methode 2 beter is dan jouw methode 1?

[Infinitive]

De mensen in dit topic hebben echt niet als doel je voor schut te zetten of in de grond te boren hoor TS, of om per sé hun gelijk te halen

Wat ze willen is dat je afziet van je datamodel. Je kiest voor een model alleen op grond van (twijfelachtige) performance. In de praktijk is gebleken dat zoiets niet handig is en dat er naast performance vele andere kwaliteitsaspekten zijn. Bijvoorbeeld onderhoudbaarheid, eenvoud en daarnaast speelt iets subjectiefs als smaak ook nog een rol.

Bekende slogans als "Premature optimalisation is the root of all evil" enzo.

[Verwijderd]

curry684 schreef op 21 juni 2004 @ 17:00:
[...]

Open dan geen topic waarin je om suggesties vraagt als je ze toch niet wil lezen.

Ten tijde van openen had ik nog geen benchmark gedaan. Een benchmark was 1 van de suggesties, die heb ik opgevolgd. Daarna heb ik het resultaat gepost en toen sprongen jullie er allemaal op.

[Verwijderd]

Infinitive schreef op 21 juni 2004 @ 17:03:
Bekende slogans als "Premature optimalisation is the root of all evil" enzo.

I know Maar het is ook bekend dat vele druppels een emmer kunnen vullen, maw als je geen grote optimalisaties meer kunt doen, kijk naar de kleintjes en met een beetje geluk vormen alle kleine optimalisaties toch weer een redelijke performance winst.

[Creepy]

Verwijderd schreef op 21 juni 2004 @ 17:03:
[...]

Ten tijde van openen had ik nog geen benchmark gedaan. Een benchmark was 1 van de suggesties, die heb ik opgevolgd. Daarna heb ik het resultaat gepost en toen sprongen jullie er allemaal op.

En dat komt omdat je onze suggesties in je benchmark niet meeneemt, bijv. dat datamodel zoals DRM dat aangeeft

[Verwijderd]

dusty schreef op 21 juni 2004 @ 17:03:
[...]

Jouw methode 2 is beter dan onze methode 3 omdat jouw methode 2 beter is dan jouw methode 1?

Dat is een combinatie van benchmark en gewoon logisch nadenken. Maar ik herhaal me wederom

[ Voor 8% gewijzigd door Verwijderd op 21-06-2004 17:08 ]

[curry684]

Verwijderd schreef op 21 juni 2004 @ 17:03:
[...]

Ten tijde van openen had ik nog geen benchmark gedaan. Een benchmark was 1 van de suggesties, die heb ik opgevolgd. Daarna heb ik het resultaat gepost en toen sprongen jullie er allemaal op.

En mag ik vragen hoe je gebenched hebt? Op een reallife productieserver met regelmatige updates en selects? Heb je indexen op kolommen liggen? Wat voor data gaat het uberhaupt over? Wordt de data ook nog voor OLAP of andere analytische vragen gebruikt? Groeien de tabellen regelmatig, worden ze groot, zijn er meer updates dan inserts etc. etc. etc.

Vertel eens wat over je datamodel, en overtuig ons aub van je gelijk. Met "uit test blijkt methode A 5% sneller dan methode B" kunnen we niets, we moeten toch op z'n minst weten wat je hoe gebenched hebt.

[curry684]

Verwijderd schreef op 21 juni 2004 @ 17:06:
[...]

I know Maar het is ook bekend dat vele druppels een emmer kunnen vullen, maw als je geen grote optimalisaties meer kunt doen, kijk naar de kleintjes en met een beetje geluk vormen alle kleine optimalisaties toch weer een redelijke performance winst.

Ik denk persoonlijk dat je goeie indexes veel meer winst kunt bereiken maja. Dat is afhankelijk van het gebruik van je database, en daar vertel je weinig over. Heb je er al eens een profiler overheen gehaald?

[Verwijderd]

Zo diep ben ik er ook weer niet in gegaan, het gaat hier om een kleine performance winst, waarvan ik weet dat ik de goede beslissing heb genomen. Jullie kunnen jullie zelf overtuigen door m'n datamodel te pakken hem te vullen en alle 2 (of 3 inclusief drm's model) de methoden te benchmarken.

[dusty]

Verwijderd schreef op 21 juni 2004 @ 17:07:
[...]
Dat is een combinatie van benchmark en gewoon logisch nadenken. Maar ik herhaal me wederom

Ehh.. ff een wiskundige voorbeeld dan.

Ik heb 3 getallen in mijn hoofd... a,b en c.

Met een benchmark toon je aan dat b groter is dan a.

Wat kan je nu over c zeggen t.o.v. b?

[curry684]

Verwijderd schreef op 21 juni 2004 @ 17:12:
Zo diep ben ik er ook weer niet in gegaan, het gaat hier om een kleine performance winst, waarvan ik weet dat ik de goede beslissing heb genomen.

Ja doei je hebt op basis van gokwerk dus een beslissing genomen, weet zeker dat het de juiste is, en wil nu niet luisteren naar advies over hoe je normaliter een database optimaliseert

Stap 1 is normaal gesproken toch echt "analyseer welke queries hoe vaak op welke momenten plaatsvinden"

[edit]

Heb je ondertussen de filebased oplossing ook al gebenched trouwens? Die is namelijk gegarandeerd sneller dan allebei jouw versies.

[ Voor 12% gewijzigd door curry684 op 21-06-2004 17:17 ]

[Verwijderd]

curry684 schreef op 21 juni 2004 @ 17:10:
[...]

Ik denk persoonlijk dat je goeie indexes veel meer winst kunt bereiken maja. Dat is afhankelijk van het gebruik van je database, en daar vertel je weinig over. Heb je er al eens een profiler overheen gehaald?

Het enigste wat hier van belang is is volgens mij het datamodel wat ik noemde (1 tabel, als je methode 1. pakt met 150 kolommen, bij methode 2. met 2 kolommen).

Natuurlijk zijn dit niet alle tabellen, maar het ging me echt om die tabel en om het feit of 150 kolommen sneller/langzamer zou zijn dan 2 kolommen in combinatie met explode.

[Verwijderd]

curry684 schreef op 21 juni 2004 @ 17:15:
[...]

Ja doei je hebt op basis van gokwerk dus een beslissing genomen, weet zeker dat het de juiste is, en wil nu niet luisteren naar advies over hoe je normaliter een database optimaliseert

Stap 1 is normaal gesproken toch echt "analyseer welke queries hoe vaak op welke momenten plaatsvinden"

Ik weet hoe je een database optimaliseert, die stap ligt zoals gezegd al achter mij. Mijn interesse ging uit naar het verschil tussen 150 kol en explode (zie orginele post). Daar geef ik niet m'n totale datamodel aan, ik geef eigenlijk een simpel voorbeeld zonder al te veel poespas, juist om niet te vervallen in andere discussies.

[curry684]

Verwijderd schreef op 21 juni 2004 @ 17:19:
[...]

Ik weet hoe je een database optimaliseert, die stap ligt zoals gezegd al achter mij.

Merk ik niet veel van. I repeat: heb je al een profiler gebruikt?

[dusty]

Verwijderd schreef op 21 juni 2004 @ 17:19:
[...]
Ik weet hoe je een database optimaliseert,
[..]

Mooi, in welke normaalvorm verkeert je database model nu?

[ Voor 2% gewijzigd door dusty op 21-06-2004 17:23 . Reden: nederlandsch :P ]

[Verwijderd]

curry684 schreef op 21 juni 2004 @ 17:20:
[...]

Merk ik niet veel van. I repeat: heb je al een profiler gebruikt?

Nee, het datamodel is simpel genoeg om het mbv logisch nadenken in combinatie met ervaring te optimaliseren. (lees: weinig relaties, nauwelijks joins en de joins die er zijn daar heb ik zowat alle combinaties van getest).

[curry684]

Verwijderd schreef op 21 juni 2004 @ 17:24:
[...]

Nee, het datamodel is simpel genoeg om het mbv logisch nadenken in combinatie met ervaring te optimaliseren. (lees: weinig relaties, nauwelijks joins en de joins die er zijn daar heb ik zowat alle combinaties van getest).

Ergo je weet niets, maar dan ook niets, over hoe je database werkt en of je globaal gezien je database nu aan het remmen of versnellen bent.

[Ralluph]

Verwijderd schreef op 21 juni 2004 @ 17:12:
Zo diep ben ik er ook weer niet in gegaan, het gaat hier om een kleine performance winst, waarvan ik weet dat ik de goede beslissing heb genomen. Jullie kunnen jullie zelf overtuigen door m'n datamodel te pakken hem te vullen en alle 2 (of 3 inclusief drm's model) de methoden te benchmarken.

De koppigheid van de TS is opmerkelijk.

Wellicht is het een goede nieuwe invalshoek van jouw probleem om eens te bedenken wat het je waard is om zulke rare fratsen (lees: jouw datamodel) uit de kast te trekken als je er maar hooguit een kleine performancewinst mee behaalt. Wanneer jij over een kleine performancewinst spreekt, dan denk ik aan enkele procenten tot tienden van procenten snelheidswinst per transactie (ervan uitgaande dat we performance puur in executiesnelheid meten) t.o.v. de huidige situatie. Is het dan niet veel gemakkelijker om te investeren in extra hardware? Dat scheelt je een hoop kopzorgen en als je applicatie echt bedrijfskritisch is dan kun je je opdrachtgevers best overtuigen van het belang hiervan. Als opdrachtgever zou ik daar sowieso meer vertrouwen in hebben dan wanneer mij ter ore zou komen dat je veel tijd besteedt aan het klussen van een dergelijke hack.

offtopic:
Bedenk eens hoeveel tijd er al in dit topic is gaan zitten. Dit is geenszins bedoeld als demotivatie, want de vermaakfactor voor de andere GoTters mag natuurlijk niet worden onderschat.

offtopic:
En als je dan toch bezig bent met upgraden, vergeet dan niet om ook het RDBMS mee te nemen in je overweging.

[ Voor 5% gewijzigd door Ralluph op 21-06-2004 17:30 ]

[Verwijderd]

dusty schreef op 21 juni 2004 @ 17:22:
[...]

Mooi, in welke normaalvorm verkeert je database model nu?

Ik heb niet genormaliseerd, want ik ben meteen uitgegaan van een tabel structuur die geoptimaliseerd is voor performance. Duplicatie van data in verschillende tabellen is in dit geval toegelaten. Als je verder normaliseerd bestaat de kans dat de performance er onder leid en dat moet juist niet.

[curry684]

Verwijderd schreef op 21 juni 2004 @ 17:29:
[...]

Ik heb niet genormaliseerd, want ik ben meteen uitgegaan van een tabel structuur die geoptimaliseerd is voor performance. Duplicatie van data in verschillende tabellen is in dit geval toegelaten. Als je verder normaliseerd bestaat de kans dat de performance er onder leid en dat moet juist niet.

Heb je wel eens van het verschil tussen OLTP en OLAP gehoord? En waarom OLTP-servers uitgenormaliseerd zijn en OLAP-servers 1 of meerdere keren per dag de data denormaliseren?

[Verwijderd]

Ralluph schreef op 21 juni 2004 @ 17:28:
[...]

De koppigheid van de TS is opmerkelijk.

Wellicht is het een goede nieuwe invalshoek van jouw probleem om eens te bedenken wat het je waard is om zulke rare fratsen (lees: jouw datamodel) uit de kast te trekken als je er maar hooguit een kleine performancewinst mee behaalt. Wanneer jij over een kleine performancewinst spreekt, dan denk ik aan enkele procenten tot tienden van procenten snelheidswinst per transactie (ervan uitgaande dat we performance puur in executiesnelheid meten) t.o.v. de huidige situatie. Is het dan niet veel gemakkelijker om te investeren in extra hardware? Dat scheelt je een hoop kopzorgen en als je applicatie echt bedrijfskritisch is dan kun je je opdrachtgevers best overtuigen van het belang hiervan. Als opdrachtgever zou ik daar sowieso meer vertrouwen in hebben dan wanneer mij ter ore zou komen dat je veel tijd besteedt aan het klussen van een dergelijke hack.
[offtopic]Bedenk eens hoeveel tijd er al in dit topic is gaan zitten. Dit is geenszins bedoeld als demotivatie, want de vermaakfactor voor de andere GoTters mag natuurlijk niet worden onderschat.

Het is een persoonlijk projectje. Als ik het voor m'n werk had gedaan had ik het allang opgegeven en gevraagd om een snellere server. Maar zo'n server en de hosting kosten kan ik persoonlijk niet betalen. Dus ik ben wel aangewezen tot hacks.

[dusty]

Verwijderd schreef op 21 juni 2004 @ 17:29:
[...]
Ik heb niet genormaliseerd, want ik ben meteen uitgegaan van een tabel structuur die geoptimaliseerd is voor performance. Duplicatie van data in verschillende tabellen is in dit geval toegelaten. Als je verder normaliseerd bestaat de kans dat de performance er onder leid en dat moet juist niet.

Hoeveel normalisatievormen zijn er?

[Verwijderd]

curry684 schreef op 21 juni 2004 @ 17:30:
[...]

Heb je wel eens van het verschil tussen OLTP en OLAP gehoord? En waarom OLTP-servers uitgenormaliseerd zijn en OLAP-servers 1 of meerdere keren per dag de data denormaliseren?

Gelukkig nooit van gehoord, want ik heb er nooit mee te maken gehad. Kan de kennis over OL*P handig zijn als je alleen beschikking hebt over PHP/mysql? Zo ja, dan verdiep ik me erin, zo niet dan niet.

[Verwijderd]

dusty schreef op 21 juni 2004 @ 17:34:
[...]
Hoeveel normalisatievormen zijn er?

Hoeveel is 1+1? Is dit een soort test? Die tijd ligt al jaren achter mij. Dit is wel een erg laag niveau waarop je je bevind dusty. Maar zoals een moderator het zei, laten we niet op persoonlijk vlak houden.

[ Voor 12% gewijzigd door Verwijderd op 21-06-2004 17:40 ]

[curry684]

Verwijderd schreef op 21 juni 2004 @ 17:33:
[...]

Het is een persoonlijk projectje. Als ik het voor m'n werk had gedaan had ik het allang opgegeven en gevraagd om een snellere server.

That's the true spirit: als het niet snel genoeg is hebben we snellere hardware nodig, want aan onze software kan het niet liggen! \o/

Van dat soort volk krijgt de hele IT-branche helaas een slechte naam

[Ralluph]

Verwijderd schreef op 21 juni 2004 @ 17:33:
[...]

Het is een persoonlijk projectje. Als ik het voor m'n werk had gedaan had ik het allang opgegeven en gevraagd om een snellere server. Maar zo'n server en de hosting kosten kan ik persoonlijk niet betalen. Dus ik ben wel aangewezen tot hacks.

Tja, dan ligt het natuurlijk anders. Zou je mij dan kunnen uitleggen waarom het dan alsnog zo belangrijk is dat de transactietijd wordt geoptimaliseerd. Die paar milliseconden zullen toch niet echt merkbaar zijn op het totaal van een pagina-request. De totale roundtrip-tijd is immers van veel meer factoren afhankelijk, die veelal een veel grotere invloed hebben. Ik probeer maar te zeggen: houd het realistisch.
Bovendien, ik denk niet dat de MySQL-beheerder (de server wordt vast en zeker gedeeld met meerdere klanten) vrolijk wordt als jij full-pull aan de server lurkt.

[dusty]

Verwijderd schreef op 21 juni 2004 @ 17:38:
[...]
Hoeveel is 1+1? Is dit een soort test? Die tijd ligt al jaren achter mij. Dit is wel een erg laag niveau waarop je je bevind dusty. Maar zoals een moderator het zei, laten we niet op persoonlijk vlak houden.

Jij wilt niet luisteren naar advies, jij houd bij hoog en laag vol dat je gelijk hebt. En de enige methode die ik weet om anders aan te tonen is om jou wat simpele vragen te laten beantwoorden waardoor ik kan aantonen dat het niet correct is, immers als je de materie kent zou je dat ook toepassen. Jij doet dat hier niet maar je spreekt wel alsof je er verstand van hebt.

Om die illusie weg te nemen bij beginnende programmeurs die hier komen, en denken aan jou een voorbeeld te nemen.

Jij kan aantonen dat je gelijk hebt bij de vragen te beantwoorden ( dat was trouwens de laatste vraag die ik nodig hebt.. FYI )

Jij geeft te kennen de materie te kennen met het antwoord dat je geeft op hoeveel normalisatie vormen er zijn, en ik toon aan van de hand daarvan dat jij de materie niet kent. Lijkt me duidelijk zat.

[Ralluph]

curry684 schreef op 21 juni 2004 @ 17:42:
[...]

That's the true spirit: als het niet snel genoeg is hebben we snellere hardware nodig, want aan onze software kan het niet liggen! \o/

Van dat soort volk krijgt de hele IT-branche helaas een slechte naam

Dat is waar, maar de keuze tussen uren spenderen aan een smerige oplossing (die de onderhoudbaarheid en doorzichtigheid van de applicatie ondermijnt) of investeren in een geupgrade/extra/snellere doos lijkt mij vanuit het perspectief van een projectmanager niet zo lastig om te maken.

[Sybr_E-N]

Verwijderd schreef op 21 juni 2004 @ 17:38:
[...]

Hoeveel is 1+1? Is dit een soort test? Die tijd ligt al jaren achter mij. Dit is wel een erg laag niveau waarop je je bevind dusty. Maar zoals een moderator het zei, laten we niet op persoonlijk vlak houden.

Als jij het zo goed weet, waarom open je dan een topic met een vraag waarop je zelf het antwoord al weet? Er worden serieuze suggesties gedaan en op/aan-merkingen gemaakt over jouw standpunt. Waarom sla je die zomeer in de wind?

Als jij duidelijk en helder voor de geest kan halen hoe een relationele database in elkaar steekt kom je er al snel achter dat zowel '150 kolomen' als '2 a 3 kolomen met '|' gesplitte data' niet efficient is. Ja, wellicht als je er 10 rows in opslaat, maar hoe gaat het zich uitpakken wanneer er 600.000 of meer rows in je database staan? Hier kom je alleen maar achter door uitgebreide te gaan lopen testen en de verschillende opties met elkaar te gaan vergelijken.

Alleen ik snap niet hoe jij erbij komt dat joins juist langzamer zouden zijn? Totzover mij op school/ boeken/ internet is geleerd dat joins er juist voor zijn uitgevonden om data zo snel en effiecient mogelijk op te halen uit de database.

[bigbeng]

curry684 schreef op 21 juni 2004 @ 17:42:
[...]

That's the true spirit: als het niet snel genoeg is hebben we snellere hardware nodig, want aan onze software kan het niet liggen! \o/

Van dat soort volk krijgt de hele IT-branche helaas een slechte naam

offtopic:
tsk tsk Curry, je bent nu de TS bijna direct aan het beledigen.

Ralluph schreef op 21 juni 2004 @ 17:47:
[...]

Dat is waar, maar de keuze tussen uren spenderen aan een smerige oplossing (die de onderhoudbaarheid en doorzichtigheid van de applicatie ondermijnt) of investeren in een geupgrade/extra/snellere doos lijkt mij vanuit het perspectief van een projectmanager niet zo lastig om te maken.

Maar het gaat niet alleen om smerige oplossingen, er komen hier ook zinvolle optimalisatie suggesties voor die een upgrade naar een nieuwe machine kunnen uitstellen of zelfs overbodig maken. Dus zo makkelijk is de keus niet altijd.

[Verwijderd]

Dusty en curry: let it go. Jullie zijn imo wel erg druk bezig jullie eigen gelijk te halen en willen persé aantonen dat TS geen verstand heeft van databases. De vraag 'hoeveel normaalvormen zijn er?' wordt alleen gesteld om aan te tonen dat TS er geen verstand van heeft, een bewijs waar niemand wat aan heeft.

Dan voor TS: Je zit hier niet met domme nitwits te praten. Je geeft zelf aan dat je aan het optimaliseren bent, en dat je in de fase van 'de kleine druppels' beland bent.

Als je dan hier komt vragen om advies vind ik het wel zo netjes om dat advies op z'n minst eens een kans te geven, of er op z'n minst geen uitspraken over te doen.

Je beweert dat jouw oplossing sneller is, zonder de geadviseerde oplossing zelfs maar getest te hebben, nogal logisch dat je daar opmerkingen over krijgt. 'Ja maar ik heb gebenched'; dat heb je dus niet. Althans niet de door DRM voorgestelde oplossing.

Zeg dan gewoon 'die oplossing wil ik niet, en daar heb ik geen goede redenen voor, basta'.

Needles to say dat de oplossing die je nu hebt meer is dan een hack; hij is gewoon extreem smerig, zo ongeveer het schoolvoorbeeld van 'meest foute actie om uit te halen'. Kan zo de boekjes in, nofi. Het ophalen van afzonderlijke kolommen is langzaam, weet je wat: we pleuren alles in 1 kolom.

Hoe gaat MySQL om met zulke brede velden? Wat voor datatype hangt hij daaraan, hoe leest hij dat in? Het zou me niets verbazen als het uitlezen van 1 kolom met 10000 tekens een stuk langzamer is dan 10 kolommmen met 1000 tekens, enz.

Maar dat weet je niet, want dat heb je niet getest.

//edit
als antwoord op de vraag: waarom zou dat sneller zijn? zou ik willen geven: 'omdat er hier mensen zijn die er echt verstand van hebben, en die zeggen dat'.

[ Voor 8% gewijzigd door Verwijderd op 21-06-2004 17:56 ]

[bigbeng]

Sybr_E-N schreef op 21 juni 2004 @ 17:50:
[...]
Alleen ik snap niet hoe jij erbij komt dat joins juist langzamer zouden zijn? Totzover mij op school/ boeken/ internet is geleerd dat joins er juist voor zijn uitgevonden om data zo snel en effiecient mogelijk op te halen uit de database.

Het openen van indexen op meerdere tabellen en het matchen van join voorwaarden brengen wel kosten in performance met zich mee. In de meeste gevallen valt dat te verwaarlozen, maar niet altijd. De precieze redenen weet ik niet meer, maar dit is wat een (voor zover ik weet goede) dba-er me eens vertelde.

[GlowMouse]

bigbeng schreef op 21 juni 2004 @ 17:55:
In de meeste gevallen valt dat te verwaarlozen, maar niet altijd. De precieze redenen weet ik niet meer

Op strings joinen is meestal een stuk trager. Op geïndexeerde integers joinen gaat snel.

[Verwijderd]

curry684 schreef op 21 juni 2004 @ 17:42:
[...]

That's the true spirit: als het niet snel genoeg is hebben we snellere hardware nodig, want aan onze software kan het niet liggen! \o/

Van dat soort volk krijgt de hele IT-branche helaas een slechte naam

Als een team goede software maakt en men weet dat het evenwicht tussen onderhoudbaarheid en performance is bereikt, dan is het een stuk goedkoper en slimmer om na een extra evaluatie een extra server erbij te zetten dan te gaan sleutelen aan de code.

[Verwijderd]

Verwijderd schreef op 21 juni 2004 @ 17:54:
Dusty en curry: let it go. Jullie zijn imo wel erg druk bezig jullie eigen gelijk te halen en willen persé aantonen dat TS geen verstand heeft van databases. De vraag 'hoeveel normaalvormen zijn er?' wordt alleen gesteld om aan te tonen dat TS er geen verstand van heeft, een bewijs waar niemand wat aan heeft.

Dan voor TS: Je zit hier niet met domme nitwits te praten. Je geeft zelf aan dat je aan het optimaliseren bent, en dat je in de fase van 'de kleine druppels' beland bent.

Als je dan hier komt vragen om advies vind ik het wel zo netjes om dat advies op z'n minst eens een kans te geven, of er op z'n minst geen uitspraken over te doen.

Je beweert dat jouw oplossing sneller is, zonder de geadviseerde oplossing zelfs maar getest te hebben, nogal logisch dat je daar opmerkingen over krijgt. 'Ja maar ik heb gebenched'; dat heb je dus niet. Althans niet de door DRM voorgestelde oplossing.

Zeg dan gewoon 'die oplossing wil ik niet, en daar heb ik geen goede redenen voor, basta'.

Needles to say dat de oplossing die je nu hebt meer is dan een hack; hij is gewoon extreem smerig, zo ongeveer het schoolvoorbeeld van 'meest foute actie om uit te halen'. Kan zo de boekjes in, nofi. Het ophalen van afzonderlijke kolommen is langzaam, weet je wat: we pleuren alles in 1 kolom.

Hoe gaat MySQL om met zulke brede velden? Wat voor datatype hangt hij daaraan, hoe leest hij dat in? Het zou me niets verbazen als het uitlezen van 1 kolom met 10000 tekens een stuk langzamer is dan 10 kolommmen met 1000 tekens, enz.

Maar dat weet je niet, want dat heb je niet getest.

//edit
als antwoord op de vraag: waarom zou dat sneller zijn? zou ik willen geven: 'omdat er hier mensen zijn die er echt verstand van hebben, en die zeggen dat'.

Dit is een mooi voorbeeld hoe je niet discussiert Wat je leert op school kan niet in alle gevallen toegepast worden en is in sommige gevallen zelfs verkeerd. Als je m'n replies leest kun je lezen dat ik redenen aangeef. DRM oplossing is logische wijze langzamer dan oplossing 2. , dat weet iedereen die net met databases begonnen is. Mag een OP niet op reacties die hij krijgt reageren?

[dusty]

Verwijderd schreef op 21 juni 2004 @ 17:54:
Dusty en curry: let it go. Jullie zijn imo wel erg druk bezig jullie eigen gelijk te halen en willen persé aantonen dat TS geen verstand heeft van databases. De vraag 'hoeveel normaalvormen zijn er?' wordt alleen gesteld om aan te tonen dat TS er geen verstand van heeft, een bewijs waar niemand wat aan heeft.

Ik heb reeds opgegeven om de gedachten van de TS te veranderen, wat ik wel kan doen is dat andere mensen die deze topic vinden niet dezelfde fout gaan maken en denken dat de TS gelijk heeft.

De vraag hoeveel normaalvormen er zijn is juist vanwege zijn verhaaltje dat hij niet heeft genormaliseerd en zijn reden qua snelheid. Vrijwel iedereen weet dat er 5 normalisatie vormen zijn, maar de meeste mensen gaan ook alleen maar normaliseren tot de 3e normaalvorm. Juist in die twee laatste normalisatie stappen komen dubbele waardes terug om het geheel sneller te maken waar dat nodig is. (denk aan het aantal topics in een sub-forum opslaan in de tabel waar de forum is gedefinieerd, immers wilt niemand de hele tijd alle topics gaan tellen.)

Zijn reden om dus niet te gaan normaliseren slaat nergens op, mocht hij niet weten dat er 5 normalisatie vormen zijn, kan ik begrijpen waarom hij die reden gaf, en had ik deze informatie aan hem kunnen geven, waardoor hij verder in normalisatie kan gaan kijken en meer snelheid winst kan behalen. Mocht hij wel weten dat er 5 normalisatie vormen waren dan zou hij zichzelf tegenspreken met zijn statement waarom hij niet heeft genormaliseerd. dus zou ik die vraag alleen maar stellen om aan te geven dat hij fout zat ( als hij het fout had beantwoord) was het inderdaad alleen maar geweest om te laten zien dat hij fout was, echter was dat niet mijn opzet, ik wou aantonen dat hij juist wel moet normaliseren, waardoor hij juist wel snelheid winst gaat maken. Juist vanwege dat antwoord zouden andere mensen er wel wat aan hebben, misschien de TS niet, immers verwacht(e) ik niet dat de TS zijn mening bij zou stellen.

[dusty]

Verwijderd schreef op 21 juni 2004 @ 18:15:
[...]
DRM oplossing is logische wijze langzamer dan oplossing 2. , dat weet iedereen die net met databases begonnen is.

Het is voor mij nogal een tijdje geleden dat ik met database's ben begonnen, zou jij mij dan die logische wijze kunnen uitleggen? want daar ben ik persoonlijk wel benieuwd naar.

[Verwijderd]

Sybr_E-N schreef op 21 juni 2004 @ 17:50:
[...]


Als jij het zo goed weet, waarom open je dan een topic met een vraag waarop je zelf het antwoord al weet? Er worden serieuze suggesties gedaan en op/aan-merkingen gemaakt over jouw standpunt. Waarom sla je die zomeer in de wind?

Ik kon inderdaad beter bij phpbuilder.com m'n vraag kwijt, daar geven ze direct antwoord wat sneller is en wat niet :-) Maar al die suggesties en de discussie die er op volgt is ook best handig. Van OLAP had ik nooit gehoord, maar ik ga er toch eens naar kijken, misschien is het wel handig voor andere projecten. Wie weet.

Als jij duidelijk en helder voor de geest kan halen hoe een relationele database in elkaar steekt kom je er al snel achter dat zowel '150 kolomen' als '2 a 3 kolomen met '|' gesplitte data' niet efficient is. Ja, wellicht als je er 10 rows in opslaat, maar hoe gaat het zich uitpakken wanneer er 600.000 of meer rows in je database staan? Hier kom je alleen maar achter door uitgebreide te gaan lopen testen en de verschillende opties met elkaar te gaan vergelijken.

Ik heb m'n simpele benchmark gedaan om data zoals deze in de database stonden (wel een kopie gemaakt), dus dat zit wel snor.

[whoami]

Als je nu 150 kolommen hebt, of 2 kolommen waarin je al die velden concateneert, dat maakt niet uit.
Het is beiden niet efficiënt; al die (irrelevante) gegevens moeten in het geheugen geladen worden en over het netwerk verzonden worden.

Daarbij komt nog eens dat de integriteit van je data op die manier niet te bewaken is, dat je opzet innefficiënt is mbt UPDATE's / INSERT's / DELETE's.....

Maar goed, je kunt zo evengoed tegen een steenezel praten. Ik stop hier geen energie in.

[Verwijderd]

dusty schreef op 21 juni 2004 @ 18:20:
[...]

Het is voor mij nogal een tijdje geleden dat ik met database's ben begonnen, zou jij mij dan die logische wijze kunnen uitleggen? want daar ben ik persoonlijk wel benieuwd naar.

Voor de laatste keer:
1 select met 1 where statement zoals select * from test where id=7 op een tabel met 2 kolommen (+de explode) is sneller dan: een join tussen 2 of 3 tabellen die resulteert in 150 records. En daarvoor hoe je geen benchmark te maken dat kun je aanvoelen. (effecten van explode had ik wel gebenchmarkt, want dat is lastig aan te voelen)

[drm]

kogels:
En daarvoor hoe je geen benchmark te maken dat kun je aanvoelen. (effecten van explode had ik wel gebenchmarkt, want dat is lastig aan te voelen)

Ik kan wel aanvoelen dat dit nergens toe leidt.

Ik stel voor dat je of met harde feiten komt (en niet van die halfzachte intuitieve kletskoek) of dat we met z'n allen dit topic laten voor wat het is.

FTR: je komt hier om advies vragen en gaat vervolgens verdedigen dat je eigen methode toch eigenlijk wel beter is om dat dat nou eenmaal goed aanvoelt. Excuse my french, maar dat is echt bullcrap waar niemand iets mee opschiet. NOFI.

[Verwijderd]

whoami schreef op 21 juni 2004 @ 18:26:
Als je nu 150 kolommen hebt, of 2 kolommen waarin je al die velden concateneert, dat maakt niet uit.
Het is beiden niet efficiënt; al die (irrelevante) gegevens moeten in het geheugen geladen worden en over het netwerk verzonden worden.

Daarbij komt nog eens dat de integriteit van je data op die manier niet te bewaken is, dat je opzet innefficiënt is mbt UPDATE's / INSERT's / DELETE's......

Als je m'n replies had gelezen had je kunnen weten dat performance erg belangrijk is, dus integriteit is niet belangrijk als het de performance negatief beinvloed. Hoe lang UPDATE's duren is toch niet belangrijk? De meeste queries zullen SELECT's zijn, dus daar moet je je op concentreren. Ik maak overigens nu van de 150 kolommen 1 kolom.

Dit is de beste (wbt performance) oplossing die bij mij bekend is.

[Verwijderd]

drm schreef op 21 juni 2004 @ 18:33:
[...]
FTR: je komt hier om advies vragen en gaat vervolgens verdedigen dat je eigen methode toch eigenlijk wel beter is om dat dat nou eenmaal goed aanvoelt. Excuse my french, maar dat is echt bullcrap waar niemand iets mee opschiet. NOFI.

Dat is logisch nadenken. Laat ik het dan anders zeggen:

Wie vind het volgende niet waar?
--------------
1 select met 1 where statement zoals select * from test where id=7 op een tabel met 2 kolommen (+de explode) is sneller dan: een join tussen 2 of 3 tabellen die resulteert in 150 records.
---------------
(als je uitgaat van de situatie die in deze disussie naar voren komt)

[coubertin119]

Verwijderd schreef op 21 juni 2004 @ 18:35:
[...]

Dat is logisch nadenken. Laat ik het dan anders zeggen:

Wie vind het volgende niet waar?
--------------
1 select met 1 where statement zoals select * from test where id=7 op een tabel met 2 kolommen (+de explode) is sneller dan: een join tussen 2 of 3 tabellen die resulteert in 150 records.
---------------
(als je uitgaat van de situatie die in deze disussie naar voren komt)

Logica haalt het ook niet altijd. Kan jij verkiezingsuitslagen voorspellen, puur door na te denken welke partijen er zijn?

[drm]

kogels:
Wie vind het volgende niet waar?

Het is geen kwestie van vinden of logisch nadenken, het is een kwestie van weten waar je mee bezig bent. En om je vraag te beantwoorden: als je het topic even doorleest kom je o.a. dusty, whoami, curry en mijzelf tegen die het "niet waar vinden". Laten dat nou de mensen zijn die wel eens een keer een databaseje in elkaar gedraaid hebben en rekening hebben moeten houden met performance. En laten dat dan ook projecten geweest zijn die niet zomaar in één of ander obscuur huis-, tuin- en keukensfeertje hingen...

Je hebt toch zelf ook wel in de gaten dat dit een nietes/welles verhaal wordt? Op dit moment is het heel simpel: kom met steekhoudende argumenten of 't topic gaat dicht om een hoop ergernis te voorkomen. Je hebt nu een aantal keren de kans gekregen je punten te onderbouwen en komt elke keer weer terug met 1 of andere intuitie waar geen touw aan vast te knopen is. Sorry, maar dat is geen manier van discussieren, in ieder geval niet één die we hier graag zien.

[dusty]

Verwijderd schreef op 21 juni 2004 @ 18:35:
[...]
Wie vind het volgende niet waar?
[...]

De snelheid van 150 records van 3 kolommen kan je niet vergelijken met de snelheid van 1 record met 150 kolommen.

[ Voor 41% gewijzigd door dusty op 21-06-2004 18:46 . Reden: Kwoot verkleining ]

[Infinitive]

Verwijderd schreef op 21 juni 2004 @ 18:35:
Wie vind het volgende niet waar?
--------------
1 select met 1 where statement zoals select * from test where id=7 op een tabel met 2 kolommen (+de explode) is sneller dan: een join tussen 2 of 3 tabellen die resulteert in 150 records.
---------------
(als je uitgaat van de situatie die in deze disussie naar voren komt)

Je vergeet er nog bij te zeggen dat je geïnteresseerd bent in al de waarden die in alle kolommen staan. En dat je dit maar één keer per page load ophaald.

Op zich kan je er weinig over zeggen bij dit soort kleine aantallen. Je weet niet wat de query analyser doet. Of wat het effect is van het opslaan/ophalen van een grote string tegenover kleine strings. Om nog maar te zwijgen over caching en het opbouwen van de resultset. Waarschijnlijk moet die ene string van jouw eerst wel volledig in het geheugen ingelezen worden voordat die verzonden wordt. Als je kleine resultaten hebt, dan vliegen de eerste resultaten al over de socket voordat de laatste opgehaald is. Enz. Enz.

[ Voor 4% gewijzigd door Infinitive op 21-06-2004 18:50 ]

[Verwijderd]

offtopic:
Als je 150 cols nodig hebt, lijkt het vrijwel zeker dat er een heleboel info dubbel opgeslagen wordt. Dit komt de performance ook niet tengoede, immers als er gezocht moet worden is volstaat een zoek opdracht naar 1 keer de betreffende info en niet N keer een zoek opdracht naar dezelfde info. Bovendien is de kans dan groter dat de betreffende info gecached wordt.

Kortom normaliseren naar tenminste de 4de normaalvorm... En vooral niet bokken met *h*-hacks, dat maakt de echte programmeurs kwaad.

[ Voor 9% gewijzigd door Verwijderd op 21-06-2004 18:51 ]

[Yoshi|IA2]

Verwijderd schreef op 21 juni 2004 @ 18:35:
[...]

Dat is logisch nadenken. Laat ik het dan anders zeggen:

Wie vind het volgende niet waar?
--------------
1 select met 1 where statement zoals select * from test where id=7 op een tabel met 2 kolommen (+de explode) is sneller dan: een join tussen 2 of 3 tabellen die resulteert in 150 records.
---------------
(als je uitgaat van de situatie die in deze disussie naar voren komt)

Ik ben ook nog maar pas met db's bezig (ttz: ik volgend 3e IK - DB op het LUC/tUL), en ik zou er niet aan denken om zo'n smerige boel op te zetten...
Als ik zoiets als project zou afgeven, dan ben ik zeker dat de prof. zegt dat ik volgend jaar mag terugkomen...

Wij gebruiken in projecten ook soms rip methodes omdat een db niet altijd vliegt, en we het soms wel kunnen laten vliegen met kleine hacks, maar tenminste verantwoorden wij de gemaakte keuzes met harde feiten.

[Verwijderd]

coubertin119 schreef op 21 juni 2004 @ 18:38:
[...]
Logica haalt het ook niet altijd. Kan jij verkiezingsuitslagen voorspellen, puur door na te denken welke partijen er zijn?

Dus jij vind dat:
---------------------
1 select met 1 where statement zoals select * from test where id=7 op een tabel met 2 kolommen (+de explode) langzamer is dan: een join tussen 2 of 3 tabellen die resulteert in 150 records.
---------------------
(als je uitgaat van de situatie die in deze disussie naar voren komt)

?

[Verwijderd]

Verwijderd schreef op 21 juni 2004 @ 18:50:

offtopic:
Als je 150 cols nodig hebt, lijkt het vrijwel zeker dat er een heleboel info dubbel opgeslagen wordt. Dit komt de performance ook niet tengoede, immers als er gezocht moet worden is volstaat een zoek opdracht naar 1 keer de betreffende info en niet N keer een zoek opdracht naar dezelfde info. Bovendien is de kans dan groter dat de betreffende info gecached wordt.

Ik kan je het niet kwalijk nemen, maar ik heb in 1 van m'n replies gezegd waarvoor de tabel diende

[Verwijderd]

Infinitive schreef op 21 juni 2004 @ 18:45:
[...]


Je vergeet er nog bij te zeggen dat je geïnteresseerd bent in al de waarden die in alle kolommen staan. En dat je dit maar één keer per page load ophaald.

Zie m'n orginele bericht:
"Het script heeft alle waarden in alle kolommen nodig"

Op zich kan je er weinig over zeggen bij dit soort kleine aantallen. Je weet niet wat de query analyser doet. Of wat het effect is van het opslaan/ophalen van een grote string tegenover kleine strings. Om nog maar te zwijgen over caching en het opbouwen van de resultset. Waarschijnlijk moet die ene string van jouw eerst wel volledig in het geheugen ingelezen worden voordat die verzonden wordt. Als je kleine resultaten hebt, dan vliegen de eerste resultaten al over de socket voordat de laatste opgehaald is. Enz. Enz.

Ik heb in m'n replies een aantal voorwaarden genoemt, zoals de gemiddelde lengte van de waarden. Maar dit heeft niet veel nut, omdat ik alle waarden moet hebben.

[Verwijderd]

dusty schreef op 21 juni 2004 @ 18:45:
[...]

De snelheid van 150 records van 3 kolommen kan je niet vergelijken met de snelheid van 1 record met 150 kolommen.

Waarom niet, je begint met meten als de eerste query begin en stopt met meten als de eerste query af is, vervolgens doe je stoptijd-eindtijd=tijd1. Hetzelfde doe je bij de tweede query (tijd2). Dit doet je een paar honderd keer onder realistische omstandigheden. De query die gemiddeld het korste duurt is de winnaar.

[Verwijderd]

drm schreef op 21 juni 2004 @ 18:44:
[...]
Het is geen kwestie van vinden of logisch nadenken, het is een kwestie van weten waar je mee bezig bent. En om je vraag te beantwoorden: als je het topic even doorleest kom je o.a. dusty, whoami, curry en mijzelf tegen die het "niet waar vinden". Laten dat nou de mensen zijn die wel eens een keer een databaseje in elkaar gedraaid hebben en rekening hebben moeten houden met performance. En laten dat dan ook projecten geweest zijn die niet zomaar in één of ander obscuur huis-, tuin- en keukensfeertje hingen...

Ik heb nog niemand gezien die de volgende stelling onjuist vind:
---------------
1 select met 1 where statement zoals select * from test where id=7 op een tabel met 2 kolommen (+de explode) is sneller dan: een join tussen 2 of 3 tabellen die resulteert in 150 records.
---------------
(als je uitgaat van de situatie die in deze disussie naar voren komt)

Mijn logische redenering blijkt dus correct te zijn. Als iemand het beter weet ben ik daar zeer geinteresseerd en kan ik m'n logische redenering aanpassen. Ik zal vanavond of morgen de bovenste stelling op wat andere boards posten en kijken of deze stelling onjuist is.

[GlowMouse]

Het leuke aan deze stelling is dat je hem makkelijk kunt testen. Hoeveel rijen heeft jouw huidige database/zal hij gaan hebben?

[Gomez12]

FF kijken hoor, welke van de 2 stellingen denk je dat gecached wordt??? De select / explode of de enkele select???

Bovendien snap ik niet helemaal waar de discussie over gaat, want volgens mij doe je deze query een keer per pagina. dus of je moet een paar duizend pageviews per seconde hebben of het is gewoon optimaliseren naar het niets toe ( als het al sneller is met echt benchen. )

En wat heb je nou precies gebencht??? Want ik zie hierboven wel een leuk scriptje staan wat een keer de eerste query daarna een keer de tweede query. Wauw goeie bench. Doe hem nog een keer en je krijgt er een ander resultaat. Zoek eens op testen / benchen.

btw curry: wat is een profiler???
Nog nooit van gehoord, maar zit over het algemeen dan ook alleen maar wat te spelen met mysql / access db's

curry684 schreef op 21 juni 2004 @ 17:20:
[...]

Merk ik niet veel van. I repeat: heb je al een profiler gebruikt?

[Verwijderd]

Verwijderd schreef op 21 juni 2004 @ 19:08:
---------------------
1 select met 1 where statement zoals select * from test where id=7 op een tabel met 2 kolommen (+de explode) langzamer is dan: een join tussen 2 of 3 tabellen die resulteert in 150 records.
---------------------
(als je uitgaat van de situatie die in deze disussie naar voren komt)
?

Volgens mij klopt je vraag niet. Als ik het goed begrijp heb je 150 velden die je allemaal nodig hebt, niet 150 records.

Ik zeg niet dat het perse sneller moet zijn, maar zie geen redenen waarom het langzamer zou moeten zijn. Hoe je je data ook ordent, je server moet evenveel bitjes bij elkaar sprokkelen en versturen, je wil immers alle data hebben. De verpakking is dan niet al te relevant, zolang je er geen redundantie inbouwt.

Kort gezegd.. of de database nou

code:

|1|hezik|blaat|1-2-2003|

of

code:

|1;hezik;blaat;1-2-2003|

als resultatenset verstuurt maakt weinig uit. Bij voldoende records is de overhead van de metagegevens te verwaarlozen imo.

De grootte van de resultatenset blijft dus ongeveer gelijk.

Ik weet niet hoe groot je veld met 150 kolommen erin is; maar controleer ook eens hoe mysql de zaken fysiek opslaat. Het zou me niets verbazen dat het ophalen van één fat-assed 'string' uit een DB langer duurt dan 150 'normale'.

Ik zal het heel simpel proberen uit te leggen waarom DRM's optie sneller kan zijn:

Je hebt 10 gelijke ladingen welke je bij 10 klanten moet bezorgen. Je magazijn heeft zo'n deur:

code:

|----|
|    |-----------------------------------------------------|
|                                                          |  
|                                                          |
|----------------------------------------------------------|

Nu heb je keuze voor verschillende verpakkingsmogelijkheden van je lading. Je kunt de lading in zijn geheel in 1 grote doos stoppen (voorwaarde is dat je dat dan bij alle ladingen doet). Die grote doos past slechts per één tegelijk door het hoge stuk van je magazijndeur.

Je kunt de ladingen ook splitsen in kleinere pakketjes, welke met meerdere tegelijk door de deur passen.

[glashio]

[boerenmodus]
Deze topic gaat over "relaties" horizontaal opslaan ( relatie is DE row zelf ) ipv vertikaal opslaan ( normaal model , dmv Primary & Secundairy Keys )
[/boerenmodus]

Het idee klinkt intressant.
Alleen moet je je toch echt af vragen waarom de "Developers" van o.a. MySQL aangeven dat je beter het normaal model kan gebruiken.
Tuurlijk wees Creatief! ( het kan altijd beter ) maar om nu zelf een C plugin voor MySQL te gaan maken.. klinkt makkelijker dan dat het is
( of behoor je tot de Elite ? Referentie's ? )
Een ander puntje kan zijn dat je Werk-,Opdrachtgever zekerheid wil over de stabiliteit ( MySQL versie 5 is ook nog steeds Expirimental )

• Algemene [b]Creatieve/Handige Oplossingen[/b] met MySQL vanuit me [url=http://gathering.tweakers.net/forum/list_bookmarks/0//forum]bookmarks[/url]
• [MySQL] Multiple rows update, single query?
• [MySQL] LIKE query op komma-gescheiden veld
• [mysql]oplossing query probleem zonder subqueries
• Mijn Favoriet : [SQL] snel zoeken met 2 wildcards _{Ode aan cameodski O+}

Dus wees scherp, maar doe ook aannamens van andere Dev'ers ( ze hebben zich al bewezen )

* glashio hoopt op een briljant idee/opmerking om deze draad tot een goed einde te brengen, maar blijft versteld staan van TS eigenwijsheid

[ Voor 9% gewijzigd door glashio op 21-06-2004 20:36 . Reden: flame @ TS ]

[dusty]

Verwijderd schreef op 21 juni 2004 @ 19:20:
[...]
Ik heb nog niemand gezien die de volgende stelling onjuist vind:

Ik tel hier anders 6 man die erop hebben gereageerd met een reactie die laat blijken dat ze vinden dat je stelling niet klopt.

Verwijderd schreef op 21 juni 2004 @ 19:15:
[...]
Waarom niet, je begint met meten als de eerste query begin en stopt met meten als de eerste query af is, vervolgens doe je stoptijd-eindtijd=tijd1. Hetzelfde doe je bij de tweede query (tijd2). Dit doet je een paar honderd keer onder realistische omstandigheden. De query die gemiddeld het korste duurt is de winnaar.

Meten? maar dan moet je een andere benchmark maken die deze twee meet, de benchmark die jij hebt gebruikt heeft niet deze methode gemeten, echter heb jij wel dezelfde conclusie eraan gehangen aan de hand van juist die benchmark. Immers kon dat iedereen "aanvoelen" volgens jou. Wat is het nou? kan je het nou beredeneren of moet je toch meten?

Dit is nou typisch een verschil tussen vergelijken en meten. Je kunt het verschil tussen beiden methoden meten, echter kun je niet zeggen dat 1 keer 150 velden gelijk is aan 150 keer 1 veld. (niet voor de database in iedergeval)

[whoami]

Verwijderd schreef op 21 juni 2004 @ 19:20:
[...]

Ik heb nog niemand gezien die de volgende stelling onjuist vind:
---------------
1 select met 1 where statement zoals select * from test where id=7 op een tabel met 2 kolommen (+de explode) is sneller dan: een join tussen 2 of 3 tabellen die resulteert in 150 records.

Ik vind ze onjuist.
Een RDBMS is geoptimaliseerd om met JOINS te werken. De overhead die je daardoor krijgt is miniem, en weegt totaal niet op tegen de voordelen van een goed genormaliseerd datamodel.
Het is natuurlijk wel zo dat bij datawarehouses de tabellen zo gemaakt zijn dat er door gequeried kan worden zonder veel joins te doen, maar dat is dan ook altijd historische data, waar geen updates nodig zijn.
Daarbij is het gewoon inefficiënt om al die irrelevante data terug te geven.

Ik vind het trouwens behoorlijk arrogant om alle goede adviezen die je door verschillende pro's gegeven werden in de wind te slaan zonder ze ook maar één keer verder te onderzoeken.

[Verwijderd]

whoami schreef op 21 juni 2004 @ 20:24:
[...]

Ik vind ze onjuist.
Een RDBMS is geoptimaliseerd om met JOINS te werken. De overhead die je daardoor krijgt is miniem, en weegt totaal niet op tegen de voordelen van een goed genormaliseerd datamodel.
Het is natuurlijk wel zo dat bij datawarehouses de tabellen zo gemaakt zijn dat er door gequeried kan worden zonder veel joins te doen, maar dat is dan ook altijd historische data, waar geen updates nodig zijn.
Daarbij is het gewoon inefficiënt om al die irrelevante data terug te geven.

Je spreekt je zelf tegen. Je vind de stelling dat oplossing .2 sneller is dan oplossing .3 onjuist. Maar je geeft aan dat oplossing 3. overhead heeft. Zoals eerder gezegd het gaat hier om performance. Dus je zegt eigenlijk dat oplossing 3. langzamer is dan oplossing 2., wat weer inhoud dat oplossing 2. sneller is dan oplossing 3. En dat was de orginele stelling.

Ik vind het trouwens behoorlijk arrogant om alle goede adviezen die je door verschillende pro's gegeven werden in de wind te slaan zonder ze ook maar één keer verder te onderzoeken.

Ik heb ze niet in de wind geslagen, lees de reacties maar. Alleen is het mij bekend dat oplossing 3. langzamer is dan oplossing 2., als dat bekend is hoef je niet meer naar oplossing 3. te kijken.

[Grijze Vos]

Euhm, Dusty. 5 Normaalvormen zei je? Als zijn oude oplossing de eerste normaalvorm is (1 tabel met 150 kolommen), dan telt deze nieuwe oplossing van hem dus echt wel als nulde normaalvorm hoor.

Verder, kogels, wees koppig, doe het op je eigen manier, optimaliseer lekker. Tot over een half jaar, als je je zooi een tikkie wil/moet uitbreiden, en het toch niet zo lekker loopt.

Kijk, je kunt een paar plankjes aan elkaar vast slaan, en als kast neerzetten, of een goede degelijke kast bouwen (a la Ikea, of wat ook). Zo kun je ook een mooie uitgenormaliseerde database in elkaar klussen, of jouw prutpakketje in nulde of eerste normaalvorm. Tuurlijk, het doet het, maar zodra je er te zware boeken op legt, stort je plankenkastje in elkaar, en blijft de Ikea-kast overeind.

Verder is voor mij persoonlijk het best belangrijk om een mooi, verantwoord stuk software te bouwen (zeker als het niet voor de baas is), daar passen een paar speed-hacks niet echt bij. Maar goed, als jij voldoening haalt uit je ranzige code, moet je dat zelf weten. Bovendien denk ik niet dat die 2 ms wat je wint per page je echt iets gaan opleveren, of heb je meer dan 10.000 page views per dag? 10.000 pageviews zou je bij een 2ms snelheidswinst namelijk 20 seconden op een dag schelen, poeh hee, daar doe ik het voor. Nee, geef mij maar een schaalbaar, uitbreidbaar, mooi datamodel.

[whoami]

Verwijderd schreef op 21 juni 2004 @ 20:33:
[...]

Je spreekt je zelf tegen. Je vind de stelling dat oplossing .2 sneller is dan oplossing .3 onjuist. Maar je geeft aan dat oplossing 3. overhead heeft. Zoals eerder gezegd het gaat hier om performance. Dus je zegt eigenlijk dat oplossing 3. langzamer is dan oplossing 2., wat weer inhoud dat oplossing 2. sneller is dan oplossing 3. En dat was de orginele stelling.

Ik spreek mezelf niet tegen. Ik zeg dat er overhead is, maar dat deze miniem is en niet opweegt tegen jouw systeem waarin je 150 kolommen, of 2 kolommen maar met evenveel data in het geheugen gaat lezen, terwijl je waarschijnlijk meerdere gegevens niet nodig hebt.

Daarbij is MySQL geoptimaliseerd om met joins te werken; k kan me niet voorstellen dat MySQL geoptimaliseerd is om met grote tabellen (in de breedte) te werken.

Ik heb ze niet in de wind geslagen, lees de reacties maar. Alleen is het mij bekend dat oplossing 3. langzamer is dan oplossing 2., als dat bekend is hoef je niet meer naar oplossing 3. te kijken.

Je slaat ze wel in de wind, want je test ze niet.

[glashio]

* glashio wacht totdat TS uit z'n bed gebeld word door de Storingsdienst
Melding : Applicatie,Database-crash... kom je ff fixen ( human redunanty ).

[dusty]

Grijze Vos schreef op 21 juni 2004 @ 20:34:
Euhm, Dusty. 5 Normaalvormen zei je? Als zijn oude oplossing de eerste normaalvorm is (1 tabel met 150 kolommen), dan telt deze nieuwe oplossing van hem dus echt wel als nulde normaalvorm hoor.

Kom op, niemand werkt met de nulde normaal vorm als ze een database gebruiken

[whoami]

dusty schreef op 21 juni 2004 @ 20:44:
[...]
Kom op, niemand werkt met de nulde normaal vorm als ze een database gebruiken

Niet?
* whoami kijkt naar de topicstarter.

[ Voor 4% gewijzigd door whoami op 21-06-2004 20:47 ]

[slm]

Heh.. ik ben ook niet de grootste normalisatie freak, zeker niet omdat mysql 4.x inderdaad vrij traag is met joinen, maar een tabel met 150 velden, of een tabel met 2 velden waarvan 1 veld bestaat uit 150 aparte varchars gaat zelfs mij te ver

Als je het zo hoog op hebt met alleen de technische optimalisatie kijk dan eerst eens naar andere (en misschien wel betere?) mogelijkheden voordat je een database systeem echt volledig verkracht:
(- datamodel zoveel mogelijk normaliseren om vervolgens:)
- de JOIN results te cachen in temporary text/htm/xml files. Dit is met name interessant als je veel joins over een mysql 4 server moet doen en/of grote resultsets terug krijgt en als de data niet iedere seconde wijzigt.
Daarnaast (en eventueel onafhankelijk van bovenstaande):
- gebruikmaken van geschiktere veldtypes
- gebruik maken van statische rijgroottes, dus gebruik maken van chars ipv varchars en texts waardoor de seektime van elke rij behoorlijk wordt verkort.
- betere indexen
- mysql verplichten deze indexen te gebruiken door USE INDEX() te gebruiken

Voordelen:
- overzichtelijker
- makkelijker en veiliger te onderhouden
- sneller

Nadelen:
- niet mogelijk met data die per seconde wijzigt tenzij je een geavanceerd lock mechanisme gebruikt.

NB
Overigens vraag ik me wel af hoe je die snelheidstesten hebt uitgevoerd. Heb je ook nadat je x maal 2 verschillende queries hebt uitgevoerd, ook eens de queries in volgorde omgedraaid? Tussendoor enkele andere queries gedaan?

[Ralluph]

glashio schreef op 21 juni 2004 @ 20:39:
* glashio wacht totdat TS uit z'n bed gebeld word door de Storingsdienst
Melding : Applicatie,Database-crash... kom je ff fixen ( human redunanty ).

Nee, dat gebeurt niet, want TS heeft hierboven al aangegeven dat het slechts een hobbyprojectje is. Zoals sommigen hierboven ook ook al vermoeden verwacht de TS tienduizenden requests per dag, maar wil dat wel ergens goedkoop hosten, een hobby mag immers geen, of hoogstens weinig geld kosten. Zoals ook al eerder is opgemerkt, onder andere door Grijze Vos en mijzelf, zal het procentenwerk waar deze hele optimalisatieaktie hem om te doen is nauwelijks snelheidswinst opleveren in de beleving vanuit de client.

Het kost hem in ieder geval een hoop energie om zijn speculatieve stellingname tegenover een handjevol experts te blijven volhouden. Als hij die energie had besteed aan het uitwerken van drie eenvoudige testcases/benchmarks dan had iedereen er nog wat van kunnen leren. Maarja, een hobbyprojectje doe je in je eigen tijd en die is schaars of kost toch geld, want de TS (die hoogstwaarschijnlijk per pageview betaald krijgt) is klaarblijkelijk te beroerd om dat te doen. Om een lang verhaal kort te maken: ik, en met mij waarschijnlijk vele anderen, zouden graag wat meer achtergrondinfo lezen over waarin deze ranzige constructie moet worden ingebed. Wellicht dat dit wat duidelijkheid schept in de grote vraag die iedereen bezighoudt: waarom deze koppigheid?

offtopic:
Of is het soms zo dat de TS in zijn dromen wordt geplaagd door een boze demoon die hem de gruwelijkste dingen belooft als hij niet snel de performance maximaliseert.

[ Voor 4% gewijzigd door Ralluph op 21-06-2004 21:02 ]

[Verwijderd]

deze tip had ik nog niet hier gezien :
voorwaarde: je id moet uniek zijn in de tabel

plaats eens LIMIT 1 achter je SQL-query(je krijgt dan dus altijd maar 1 row terug), dan zoekt de DB niet verder naar volgende matches en hoeft hij dus niet elke keer de hele tabel door te lopen.

dit doorlopen is nogal arbeids intensief omdat je rows dynamisch van lengte zijn als je varchar gebruikt.
tip2:
voorwaarde: je tabel is van het MyIsam tabel type
row-size fixeeren, dan is het makkelijker(lees: sneller) voor de db om uit te rekenen waar de volgende row zich op de disk bevindt.
dit doe je door alle string-data-kolommen om te zetten naar char (en je mag ook geen blob/text columns hebben want dan wordt het alsnog een dynamische tabel en soms worden je char kolommen dan ook nog stiekum varchar kolommen)
te controleren met

SQL:

SHOW TABLE STATUS FROM `jouwDbNaam`; 

en dan controleren of de kolom Row_Format "Fixed" zegt.
voordeel van Fixed is ook gelijk dat bij een crash er minder kans is op data-corruptie vanwege de vaste record lengte. nadeel is het grotere ruimte gebruik maar dat weegt niet op tegen de voordelen.
SHOW TABLE STATUS docs
Waarom Fixed?

maar normaliseren is geiler...

[whoami]

Als je een index liggen hebt op de kolom waarop je zoekt, dan valt dat zowiezo wel mee. Als die index gebruikt wordt, dan moet er zowiezo geen table-scan gebeuren en weet het DBMS wel snel of er nog rows terug te geven zijn of niet.

[Verwijderd]

offtopic:
@ whoami:
weet ik wel, maar alle beetjes helpen, en LIMIT 1 is altijd een goed idee als je maar 1 record terug wilt hebben

[Infinitive]

offtopic:
@ReSc: heeft ook nadelen: stel dat er per abuis meerdere resultaten mogelijk zijn. Dan zul je dat op deze manier niet detecteren. Via de standaard mysql functies die in php zitten, zal je zelf zo'n check niet zo snel plaatsen in je code, maar bijv. een db wrapper (bijv. speciale functie voor enkele resultaten) zou zoiets wel kunnen.

Daarnaast is LIMIT niet standaard...

[Verwijderd]

offtopic:
@ Infinitive:
de echte programmeur maakt geen fouten en weet altijd wat ie terug krijgt

en dat LIMIT geen standaard is... tis een MySQL standaard en MySQL is opzichzelf al een redelijke standaard, dat is standaard genoeg voor mij, standaard-technisch gezien dan

random quote:
Vroegah had je geen databases.
Vroegah stuurde je de loopjongen het archief in en als die dan niet snel genoeg was, gaf je hem een schop onder z'n reet.

[ Voor 19% gewijzigd door Verwijderd op 21-06-2004 22:36 ]

[goalgetter]

Ik heb met verbazing alle replies hier gelezen, maar even een vraagje aan de TS... Waarom gebruik je uberhaupt een database?

Je stelt dat onderhoudbaarheid geen issue is als de performance in het geding komt.

Als die perfomance echt zo belangrijk is gebruik dan gewoon een flatfile, dan spaar je meteen je database overhead uit. Of sterker nog, aangezien alle 150 values bij elke page-load nodig zijn, trap ze gewoon hardcoded in je script, spaart niet alleen de database overhead uit, maar ook de enorme tijd die het kost om een file uit te lezen!

Daarnaast bespaar je je allemaal trage cpu-tijd vretende hacks als explode.

[ Voor 8% gewijzigd door goalgetter op 22-06-2004 16:11 ]

[Verwijderd]

goalgetter schreef op 22 juni 2004 @ 16:10:
Daarnaast bespaar je je allemaal trage cpu-tijd vretende hacks als explode.

Het flatfile systeem was hem al voorgesteld, maar was geen optie..

[dusty]

Verwijderd schreef op 22 juni 2004 @ 19:25:
[...]
Het flatfile systeem was hem al voorgesteld, maar was geen optie..

Moet je natuurlijk ook aangeven waarom het geen optie was he

Verwijderd schreef op 21 juni 2004 @ 16:31:
[...]
Flatfile is hoogstwaarschijnlijk langzamer. Bovendien m'n script heeft al connectie naar db als ik de bovenstaande query uitvoer, de overhead van het connecten heb ik dus al achter mij liggen.