DB relaties in DBMS vs relaties in front-end

[BEHM]

Samen met een vriend van mij had ik laatst een discussie over relaties in een database.
Het betreft een database met ongeveer een dozijn tabellen en in totaliteit een dozijn relaties tussen deze tabellen.

Ik ben van mening het beter is dat de relaties gedefinieerd worden in de DBMS, in verband met data beveiliging etc. Hij vindt dat de relaties gedefinieerd moeten worden in de front-end van de applicatie vanwege de gevolgen van de ON DELETE CASCADE.

Ook beweert hij dat het de nieuwe trend is die gevolgd gaat worden. Meerdere kleine databases zonder relaties in plaats van grote db's met relaties

Mis ik hier iets en heeft hij de trend gezien?

[Kettrick]

De cascading is een manier van je database om je integriteit te bewaren, ik zou niet te veel waarde hechten aan het verhaal . Het een sluit het ander niet uit, je wil voordehandliggende dingen afvangen in je frontend, maar zeker ook afdwingen in je db.

[EfBe]

FK constraints in de DB definieren, en eventueel gebruiken in de GUI, maar niet af laten hangen van de UI. Immers, wat gebeurt er als je database langer leeft dan je applicatie (en dat komt veelal voor)? . On cascade delete is alleen aan de orde wanneer je dat aanzet, dus daar ben je zelf bij.

Ik zou zelf cascading deletes/updates uit zetten op elke FK, temeer omdat je dan geen controle hebt over wat er gebeurt en in complexe gevallen (meerdere paden door model van A naar werken ze ook niet.

[mOrPhie]

Met EfBe. Cascading deletes gebeuren alleen als het aanstaat. En ook zonder cascading deletes bewaar je de integriteit. Immers (mits je DBMS het ondersteund) bewaakt de DB deze referentiele integriteit en kun je rows alleen verwijderen als er geen referentie meer naar bestaat. Het zal in veel gevallen dus een mix worden tussen de referentiele integriteit van de DB en de logica van je DAL, waarin je zelf je constraints bedenkt op basis van hetgeen gewenst is vanuit business-perspectief (bijvoorbeeld het doen van logische deletes in plaats van fysieke, om historie te bewaren).

Ik denk dus dat je of die vriend niet hebt begrepen, of hij leeft met zijn gedachten in een fantasie-wereld. Want een database zonder referentiele integriteit is terug naar de jaren 80 en ik ken maar weinig developers die graag terugdenken aan die tijd.

In welke context had die vriend het erover? In grote enterprise systemen, in administratieve systemen voor het MKB, lokale databases of grid computing bijvoorbeeld?

[Niemand_Anders]

Wij hebben wel een database waarbij geen relaties zij gelegd tussen de tabellen, maar die database is onder controle van een enkele applicatie. Het controleren van de relaties bij inserts of deletes kan namelijk op een gegeven moment een zware load leggen op het systeem, zeker als de tabellen groter en groter worden.

De betreffende (statistieken) applicatie heeft ook geen gebruikers invoer en haalt zijn data uit andere databases. Vanwege performance problemen zijn daar de relaties verwijderd (was alleen controle en geen cacading acties) en vervolgens nam de performance van de applicatie met ruim 40% toe en hadden we ook geen last meer van query timeouts. Gegevens worden eigenlijk nooit uit de database verwijderd.

Maar relationele databases dienen in beginsel zoals de naam al aangeeft gewoon relaties te bevatten.

[corné]

Ik vind een relationele database vele malen beter werken ook omdat je dan (bijna) geen checks in de applicatie hoeft te bouwen als er bijvoorbeeld een parent wordt verwijderd en dus hoef je veel minder te coden
Maar met heeele grote databases heb ik geen ervaring.

[ Voor 3% gewijzigd door corné op 20-04-2008 12:51 ]