Archief - OO versus DB performance

Ik ben momenteel bezig aan een PHP website, maar de vraag is evengoed valid voor andere talen:

Veronderstel dat je een aantal klasses heb: A, B , C. Een object van klasse A bevat een lijst van 0 of meerdere objecten van klasse B, en elk object van klasse B bevat een lijst van 0 of meerdere objecten van klasse C.


Stel nu dat deze hiërarchie op de verschillende niveau's wordt geconsulteerd: soms is enkel de info op het eerste niveau (klasse A) nodig, soms ook het tweede (incl klasse B) en regelmatig ook het derde niveau (klasse C).


Om de nodige objecten te creëeren met de informatie uit de database, kunnen 2 manieren gebruikt worden (ga even uit van een situatie waar de 3 niveau's nodig zijn):

• we schrijven 1 query die alle nodige info opvraagt van de 3 niveau's en laten de programmeertaal deze informatie verwerken tot de correcte hiërarchie.
  • Voordeel: slechts 1 query, dus traffic naar DB server is beperkt en ook load wordt geminimaliseerd.
  • Nadeel: je werkt buiten je OO-abstracties en hebt 'zwevende' SQL code, onderhoud wordt moeilijker.
• we geven elke klasse een loadInfo() methode, dewelke voor dat ene object de info opvraagt van het niveau lager.
  • Voordeel: zeer 'proper': volledige abstractie en makkelijk te onderhouden.
  • Nadeel:véél queries wanneer deze hiërarchie een groot aantal bladeren bevat, wat gaat doorwegen op de performance. (Nu kunnen prepared statements hier wel voor wat winst zorgen.)

Dus mijn vraag: hoe pakken jullie deze zaken aan? Ik heb lang de eerste methode gebruikt uit performance overwegingen, maar de laatste tijd neig ik steeds meer naar de tweede methode, met als hoofdreden: onderhoudbaarheid.

Een goed ORM laat toe om "hints" te geven hoeveel info er nodig is, en zal deze info in één call gaan ophalen. Bij Rails is dit bvb via de "include" die je kan meegeven bij een call naar een ActiveRecord object.

Lazy instantiatie van de objecten is ook handig - bouw niet heel je objectenboom op bij het inladen van de data, maar pas als er effectief een call naar het object gedaan wordt.

Mijn antwoord is dus: het is de taak van het ORM om dit op te lossen, niet van de programmeur. De programmeur kan wel (om snelheid te winnen) extra info meegeven zodat het ORM weet wat de bedoeling is.

Uit je vraagstelling meen ik te kunnen afleiden dat je momenteel nog geen ORM gebruikt in je applicaties. Het eerste wat je dus moet doen is die tools eens nader te bekijken. Voor PHP zijn Propel en Doctrine de grootste en gekendste ORM oplossingen. Ze hebben elk hun voor- en nadelen, bekijk ze eens, experimenteer er wat mee en stel vast dat het wiel opnieuw uitvinden niet echt loont .

Thanks djeez

Ziet er inderdaad proper uit.