Efficiënt gebruik van database
Klopt mijn veronderstelling dat OOP ervoor zorgt dat je database meer gebruikt wordt voor individuele query's en de JOINS eerder wegvallen?
Als voorbeeld neem ik bijvoorbeeld een forum. De data dat in het forum aanwezig zijn: gebruikers, topics en posts
Als ik nu via OOP de posts van een bepaald topic wil gaan weergeven, dan moet ik voor elke post in het topic de objecten "posts" en "gebruikers" individueel aanroepen. Zij gaan dan op hun beurt de nodige gegevens ophalen in de database.
Wat is nu het beste?
- gewoon de objecten aanroepen, laat de query's maar komen. 20 posts in het topic zorgt voor 20x posts-query en 20x de bijhorende gebruiker-query (geeft 40 query's), maar dan wordt er niet efficiënt van de relationele database gebruik gemaakt.
- het object topics alle data van de posts en de gebruiker uit de relationele database laten halen. Echter, waarom heb ik dan nog de objecten posts en gebruiker?
Als voorbeeld neem ik bijvoorbeeld een forum. De data dat in het forum aanwezig zijn: gebruikers, topics en posts
Als ik nu via OOP de posts van een bepaald topic wil gaan weergeven, dan moet ik voor elke post in het topic de objecten "posts" en "gebruikers" individueel aanroepen. Zij gaan dan op hun beurt de nodige gegevens ophalen in de database.
Wat is nu het beste?
- gewoon de objecten aanroepen, laat de query's maar komen. 20 posts in het topic zorgt voor 20x posts-query en 20x de bijhorende gebruiker-query (geeft 40 query's), maar dan wordt er niet efficiënt van de relationele database gebruik gemaakt.
- het object topics alle data van de posts en de gebruiker uit de relationele database laten halen. Echter, waarom heb ik dan nog de objecten posts en gebruiker?
Klein dilemma inderdaad, echter zou ik toch echt in dit geval voor de performance kiezen. Je kunt dit ook oplossen door niet per post/topic de gebruiker op te zoeken, maar eerst een array te genereren (1 query) met alle users en deze vervolgens via OOP te matchen aan de posts (soort Join met tussenstap)
Ligt een beetje aan hoe je dit wilt opzetten natuurlijk en wat je belangrijker vindt. Misschien dat iemand anders daar nog een andere visie over heeft.
Ligt een beetje aan hoe je dit wilt opzetten natuurlijk en wat je belangrijker vindt. Misschien dat iemand anders daar nog een andere visie over heeft.
Gewijzigd op 10/04/2012 18:47:23 door Maikel Doeze
Hoezo zou OOP er nu voor zorgen dat een database slecht gebruikt wordt? Ik zou eerder zeggen dat een SLECHT OOP design ervoor zorgt dat de database slecht gebruikt wordt. OOP bepaalt niet hoe je je queries opbouwt en dus hoe je de data ophaalt. In tegendeel zou ik eerder willen beweren. Als je een goed design hebt waarin je de database en de data management objecten netjes loskoppelt van de rest van je applicatie krijg je juist meer mogelijkheden om het efficient te doen.
Wat jij zegt:
Hoezo "moet" dat? Niets moet, dat heb jij blijkbaar zo ontworpen. Niets in OOP bepaalt dat dat zo "moet".
Wat jij zegt:
Quote:
Als ik nu via OOP de posts van een bepaald topic wil gaan weergeven, dan moet ik voor elke post in het topic de objecten "posts" en "gebruikers" individueel aanroepen.
Hoezo "moet" dat? Niets moet, dat heb jij blijkbaar zo ontworpen. Niets in OOP bepaalt dat dat zo "moet".
Ik sluit me bij Erwin aan: Als het OOP ontwerp goed is, zal er geen probleem zijn. Ook het loskoppelen van de data management objecten is goed. Een applicatie zou je in 3 lagen kunnen opbouwen:
1. Interface (bijv. browser interface, of iPhone/Android app)
2. Programma logica
3. Data management
Een laag kan alleen maar gebruik maken van de laag daar direct onder. Data management kan dus geen gebruik maken van de interface of programma logica. De interface kan alleen gebruik maken van de programma logica. En deze kan weer alleen maar gebruik maken van data management.
Jouw probleem over 20 aparte queries om 20 posts op te halen, lijkt op een fout ontwerp. In je OOP ontwerp zou ook nog een lijst-object voor posts passen. De attributen van dit object zijn dan de selectiekenmerken. Dan zijn er wat methods (functies) van dit object om bijv. de leden van de lijst in te lezen, te verwijderen, ...
De gelezen records kan je als een array van objecten (elk 1 enkele post) teruggeven. Of als je het iets complexer wilt, kan je een iterator object teruggeven.
1. Interface (bijv. browser interface, of iPhone/Android app)
2. Programma logica
3. Data management
Een laag kan alleen maar gebruik maken van de laag daar direct onder. Data management kan dus geen gebruik maken van de interface of programma logica. De interface kan alleen gebruik maken van de programma logica. En deze kan weer alleen maar gebruik maken van data management.
Jouw probleem over 20 aparte queries om 20 posts op te halen, lijkt op een fout ontwerp. In je OOP ontwerp zou ook nog een lijst-object voor posts passen. De attributen van dit object zijn dan de selectiekenmerken. Dan zijn er wat methods (functies) van dit object om bijv. de leden van de lijst in te lezen, te verwijderen, ...
De gelezen records kan je als een array van objecten (elk 1 enkele post) teruggeven. Of als je het iets complexer wilt, kan je een iterator object teruggeven.




