Hallo!

Ik heb een vraagje over het verwerken van grote hoeveelheden data uit verschillende databasetabellen. Ik heb een tabel of 100 met daarin oer tabel 10000 records. Deze worden uitgelezen op PHP pagina's waarna de data weergegeven wordt. Nu gaat het als volgt:

10.000 records in tabel 1, daarvan worden er 100 weergegeven op de pagina. Deze 100 worden d.m.v. een 'while' loop een voor een afgegaan. Per record word er dan data in de loop verzameld uit ongeveer 10 andere databasetabellen. (Dus: voor de 100 weergegeven records worden per record 10 mysql queries gedaan op de pagina). Nu wordt de laadtijd erg traag hiervan en soms zelfs met het gevolg dat de gehele site traag wordt.

Hoe kan ik dit het best oplossen? m.b.v. caching? En zo ja, moet ik dan met een cron job gewoon de output die nu 'live' gegenereerd wordt in de .php in plaats van live laten genereren 5 keer per dag in een .txt document laten zetten die dan vervolgens in de originele .php ge-include wordt? Ik kan niet echt vinden hoe caching in zijn werk gaat en hoop dan ook dat iemand me dit kort kan uitleggen of eventueel een Nederlandse bron toe kan sturen.

Alvast bedankt!

Laten cachen naar php file en die includen op de betreffende pagina lijkt me prima.

Crontab erop en klaar is kees.

Als ik je post lees denk ik dat er ook nog wel ruimte is voor optimalisatie van je db en query's?

Ben meer geïnteresseerd in het cachen en hoe dat in zijn werk gaat. Of ik inderdaad de data kant en klaar moet cachen in .txt documenten die vervolgens include worden in mijn PHP of dat ik bestanden moet maken waarin de 'Ruwe data' neergezet wordt waar de PHP vervolgens zijn data uit haalt.

http://www.xeweb.net/2011/11/03/simp...hing-improved/

Cachen in deze is niet de juiste oplossing, maar wel goed om te gebruiken nadat je een juiste oplossing hebt gevonden voor je "werkwijze". Je database moet relationeel opgebouwd zijn en dan kan je vaak met 1 juiste query de data opvragen zonder dat je gebruik maakt van loops waarin je nog een tientalle/honderde queries afvuurt op de database.

Als je de juiste query's maakt hoef je totaal geen relationele database te hebbben. Het kan in sommige systemen zeker van pas komen. Maar kan daarentegen ook een hoop onnodig werk kosten.

Origineel gepost door Jasper.Bollen

Als je de juiste query's maakt hoef je totaal geen relationele database te hebbben. Het kan in sommige systemen zeker van pas komen. Maar kan daarentegen ook een hoop onnodig werk kosten.

Ik schat dat 95% van de websites wereldwijd wel op een relationele rdbms draait (bv. mysql), dus ik zou eerder zeggen dat het in sommige gevallen beter is om een non-relationele db te gebruiken.

De kunst met databases is om - het liefst in één query- de informatie uit de database te halen die je nodig hebt en ook vooral niet meer dan dat je nodig hebt. Daarnaast is een juiste inrichting van de database essentieel om tot betere resultaten te komen. Denk hierbij vooral ook aan het indexeren van de juiste kolommen. Vervolgens hebben we de hardware. Als je een zware database applicatie draait op een shared host dan zul je snelheidswinst boeken door de applicatie onder te brengen op een vps.

Oke, maar hoe doe ik het volgende met één query?:

Ik heb 100 producten en wil voor die producten de prijzen weten uit een andere tabel. Dan kan het toch niet anders dan dat ik voor ieder product een aparte query uitvoer op de prijzendatabasetabel? Dus voor ieder product: SELECT * FROM prijzentabel WHERE uniekeproductcode='productcode' bijvoorbeeld. Dit kán je voor 100 producten toch niet in één query doen?

Origineel gepost door A. Hendriks

Oke, maar hoe doe ik het volgende met één query?:

Ik heb 100 producten en wil voor die producten de prijzen weten uit een andere tabel. Dan kan het toch niet anders dan dat ik voor ieder product een aparte query uitvoer op de prijzendatabasetabel? Dus voor ieder product: SELECT * FROM prijzentabel WHERE uniekeproductcode='productcode' bijvoorbeeld. Dit kán je voor 100 producten toch niet in één query doen?

Tuurlijk kan dat wel. Daarom is het tenslotte een RDBMS... (Google eens op 'joins')

-> select veldjes from tabel a, tabel b where a.key = b.key

Maar.... het hoeft niet in alle gevallen sneller te zijn. Tabels met elkaar joinen kost nu eenmaal ram en in bepaalde gevallen zelfs erg veel ram (uiteraard kan mysql wel tijdelijke tabellen aanmaken op disk bv. maar dat maakt het allemaal niet sneller).
Soms... zeker met erg veel concurrent users, kan het sneller zijn om losse selects te doen ipv. ram vretende joins.

Ik zou het toch de moeite waard vinden om het te proberen. gewoon even een test omgeving maken om te vergelijken

http://www.sitepoint.com/understandi...ysql-database/

dit legt ook even de verschillende soorten joins uit

Je moet het zeker even checken. En niet vergeten om het nogmaals te checken als je van server wisselt.

Ook wel het N+1 probleem genoemd! Eager loading is de oplossing, Is Laravel 4 heel goed in ;)

Enerzijds kan je inderdaad joins gaan gebruiken in je queries, anderszijds; wanneer data amper veranderen kan je de html volledig cachen via bijvoorbeeld varnish of deels cachen in PHP via APC of opcache.