[Alg] DBMS en OOP mapping*

[Verwijderd]

Heel leuk natuurlijk dat OOP gebeuren, maar nu even het volgende

Ik heb in m'n database een tabel met berichten, vervolgens maak ik een klasse bericht waarmee ik elk bericht uit de database op kan halen d.m.v. een query voor het bericht.

Nu wil ik een overzicht maken van bijv. de laatste 20 berichten, nu is het een beetje ranzig voor elk bericht een qeury te moeten draaien. Hoe los je zoiets netjes op?

ps. Of het nu om Java met Oracle of PHP met MySQL gaat doet er even niet toe, het gaat puur om het OOP verhaal.

[Johnny]

Met een loop

[Eskimootje]

Dan moet je een controller klasse hebben die berichten aanmaakt dan kun je vanuit die controller klasse alles ineens opvragen uit de database en daaruit de berichten maken. Dan is het OO en efficient.

[ Voor 15% gewijzigd door Eskimootje op 09-11-2003 20:32 ]

[ACM]

Je zou een versie van de constructor kunnen maken die aan de hand van een array, resultset of meerdere parameters zichzelf kan opbouwen, ipv dmv een losse query?

En dan een of andere methode ergens die de boel in elkaar fabriekt door je gewenste query te draaien (en dus per record die speciale constructor gebruikt)

[Verwijderd]

Hier kan ik wat mee Dank u!

[EfBe]

Verwijderd schreef op 09 november 2003 @ 20:28:
Heel leuk natuurlijk dat OOP gebeuren, maar nu even het volgende

Ik heb in m'n database een tabel met berichten, vervolgens maak ik een klasse bericht waarmee ik elk bericht uit de database op kan halen d.m.v. een query voor het bericht.

Nu wil ik een overzicht maken van bijv. de laatste 20 berichten, nu is het een beetje ranzig voor elk bericht een qeury te moeten draaien. Hoe los je zoiets netjes op?

ps. Of het nu om Java met Oracle of PHP met MySQL gaat doet er even niet toe, het gaat puur om het OOP verhaal.

Een goede O/R mapper biedt collection classes aan voor zn entities, dus dat je middels de collection classes groepen entities gebaseerd op een door jou opgestelde filter kan binnenhalen.

[Verwijderd]

nu heb ik mij altijd al afgevraagd: Als je een filter doet (customername = 'jef' bvb) moet dat dan gebeuren in Business logic layer of in DAL.
moet jeje sql queries filter of je arraylists filteren?

[whoami]

Filteren doe je op het niveau van de de DB.
De database is ervoor gemaakt, om de gegevens op te halen die jij wil. Als je zelf gaat beginnen filteren (in je BL bv), dan ga je de boel alleen maar vertragen.
Je gaat nl. veel te veel records ophalen in de DB, wat bandbreedte kost, en daarnaast moet je dan nog zelf eens de gewenste records eruit halen, wat je ook niet zo snel kunt doen als dat de DB het voor jou kan doen.

[Delphi32]

whoami schreef op 09 november 2003 @ 23:21:
Filteren doe je op het niveau van de de DB.
De database is ervoor gemaakt, om de gegevens op te halen die jij wil. Als je zelf gaat beginnen filteren (in je BL bv), dan ga je de boel alleen maar vertragen.
Je gaat nl. veel te veel records ophalen in de DB, wat bandbreedte kost, en daarnaast moet je dan nog zelf eens de gewenste records eruit halen, wat je ook niet zo snel kunt doen als dat de DB het voor jou kan doen.

Ik zou dat niet zo strikt willen stellen. Het hangt imho nogal af van de context waarbinnen je de filter wilt maken.
Als je een filter ziet als een gemakkelijke manier om geen queries te hoeven schrijven, dan zul je zeker aanlopen tegen het feit dat client side filtering vaak veel trager is dan filtering door de DB (lees: gebruik maken van een fatsoenlijke query).
Als je een filter wilt zien als een eenvoudige manier om een bestaande result set snel en tijdelijk te beperken tot een subset van de result set, dan zie ik weinig problemen in client-side filtering. Requerying levert in dit geval (is mijn ervaring met onze OR-mapping lib iig) een forse performance penalty op.
Alles staat of valt dus met de gehanteerde betekenis van de bedoelde Filter.

[Verwijderd]

Waarom zou je je DMBS OOP willen mappen? Het relationele model is namelijk niet goed in objecten te vangen (zonder enorm snelheidsverlies).

[whoami]

Verwijderd schreef op 10 november 2003 @ 00:43:
Waarom zou je je DMBS OOP willen mappen? Het relationele model is namelijk niet goed in objecten te vangen (zonder enorm snelheidsverlies).

Hoe ga jij anders die objecten naar een DB (een RDBMS, OODBMS zijn nu eenmaal -in mijn ervaring dan- niet echt ingeburgerd) gaan wegschrijven?

[EfBe]

Verwijderd schreef op 09 november 2003 @ 23:19:
nu heb ik mij altijd al afgevraagd: Als je een filter doet (customername = 'jef' bvb) moet dat dan gebeuren in Business logic layer of in DAL.
moet jeje sql queries filter of je arraylists filteren?

Je filters schrijf je in je BL code, want daar REQUEST je de data. Je filters formuleer je doorgaans binnen een O/R mapper met de typed objects die de O/R mapper beschikbaar stelt, bv filter predicate classes etc. De filter gaat dan naar de DAL code om te worden gebruikt voor retrieval.

[EfBe]

Verwijderd schreef op 10 november 2003 @ 00:43:
Waarom zou je je DMBS OOP willen mappen? Het relationele model is namelijk niet goed in objecten te vangen (zonder enorm snelheidsverlies).

Heel goed opgemerkt!

Maar weinig mensen snappen dit en roepen heel erg hard dat het kan en moet, maar ze snappen niet dat het relationele model geen inheritence ondersteunt bv. Het komt er dan feitelijk op neer dat je een van beide kanten moet kiezen:

1) mappen van relationele entities op classes: database puristisch, OO pragmatisch
2) mappen van OO classes op relationele entities: database pragmatisch, OO puristisch.

M.a.w.: je moet op een vlak consessies doen. Wil je dit niet, dan heb je erg ingewikkelde mappings vaak die veelal niet kunnen worden gerespecteerd voor 1 van de 4 CRUD operaties.