Database ontwerp/Applicatie design

[Flippuh]

Hoi Allemaal,
Ik vraag me het volgende af:

Gezien ik al een tijdje met een MVC pattern werk in mijn applicaties ben ik volledig bekent met het scheiden van mijn model, view en controllers.
Nu kom ik op het volgende, het scheiden van je database design en je model,
Het volgende is er aan de hand, ik heb een grote genormaliseerde database waar de komende jaren nogal wat update werk in zal zitten.
Nu is mijn applicatie natuurlijk afhankelijk van de correcte query resultaten en zou het best een b*tch kunnen zijn bij elke update op de database alle modellen door te moeten lopen en je queries te moeten updaten.
Ik heb op dit moment diverse views en functies aangemaakt die voor een aantal taken de werkelijke database structuur verstoppen voor mijn model.
(op deze manier kan ik mijn database structuur aanpassen zonder dat mijn model daar last van heeft)

Nu mijn vraag: tot in hoeverre is het verstandig dit door te voeren, ik kan als het moet alle queries die ik nu heb vervangen door functies of enkel op views laten plaats vinden. Op dit moment klinkt het mij erg interesant in de oren,..... maar waarom heb ik hier nooit eerder over gehoord?

Iemand met (goed onderbouwde) adviesen????

 

[Frats]

Zoek eens op de term "ORM".

Dat is ongeveer wat je nodig hebt Een scheiding tussen je fysieke database en je code.

 

[Flippuh]

Hoi Frats,
Tof keyword, kende de term nog niet.
Heb eventjes gezocht en kom tot het volgende:

Na wat zoeken kwam ik op doctrine uit, ziet er leuk uit en zal vast een toepassing kennen. Voor mijn huidige project lijkt het mij echter een soort sub-model dat naast mijn mvc blijft bestaan (beetje het cake idee van een model) en zal voor behoorlijk wat extra overhead zorgen (weer een stapel met php files). Ik gebruik Zend Framework vanwege de glue-like opzet (gebruik wat je wilt gebruiken, laat de rest voor wat het is) wat in tegenstelling tot cake en diverse andere frameworks je een hoop vrijheid geeft.
Ik vereis dat de controllers hun model data met losse methodes opvragen uit het model en niet zelf data gaan opvragen met een doctrine achtig systeem, als je dan queries moet gaan optimaliseren ben je echt ziek gezien je geen oog meer hebt op wat voor query er gebruikt wordt om bepaalde gegevens op te vragen, laat staan je query te optimaliseren. Is misschien leuk voor databases met 1 of 2 joins en niet meer dan 100.000 records, daarna wordt het huilen.
Op wikipedia stellen ze dat stored procedures voor sommige doeleindes beter zijn maar deze weer niet portable zijn. Ik begrijp dat niet helemaal, Ik gebruik postgresql welke stored procedures ondersteunt, samen met triggers, views en functies.
Mysql ondersteunt dit zover ik weet sinds kort ook allemaal en ga ervan uit Oracle ed. ook.
Het switchen van database server zal inderdaad wat problemen ondervinden maar daar gebruik je een mvc voor, waar je je modelen aan zal kunnen passen.

Veranderingen in je tabellen structuur kun je helemaal in je database plaats laten vinden door je views, triggers en functies aan te passen.
Denk dat dit toch wel erg interesant is.

Bedankt voor je keyword,... mocht je er nog meer kennen,... hoor ik ze graag.