fast die ganze Programmlogik findet sich in Views, Stored Procedures, Stored Functions und Triggern.
So versuchen wir es fast immer zu machen. Der große Vorteil für uns ist, daß es vollkommen egal ist, mit was der Kunde auf die Daten zugreift - die Daten sind in jedem Fall konsistent.
Außerdem ist damit unserer Erfahrung nach eine viel sauberere und konsequentere Umsetzung von Transaktionen möglich - was wieder Inkonsistenzen verhindert.
Und dann wär da noch der Geschwindigkeitsvorteil - sauber designte und umgesetzte Logik in der
DB ist gerade wenn's nicht nur im LAN laufen soll ein enormer Geschwindigkeitsvorteil.
Was immer wieder als Argument dagegen herhalten muss ist der Wechsel des
DBMS. Würde ich aber sowieso nie machen - weil man sich dann in allem was man macht immer auf den kleinsten gemeinsamen Nenner einigen muss und damit viel an Unterstützung und Geschwindigkeit die das
DBMS bietet liegen lässt.
In der Praxis hat man vermutlich immer eine Mischung von beidem, aber je nach Anwendungsfall ist die eine oder andere Ausrichtung stärker vertreten.
Genau. Mit keinem der beiden Ansäzte lässt sich gänzlich alles abdecken.
Luggi
Aus meiner Erfahrung heraus, der Weg die Daten sauber zu halten, ist die "schlaue Datenbank". Was natürlich in der Entwicklung relativ aufwendig ist, da
RAD und Selbstdokumentation nicht zu den bevorzugten Zielen der
DB-Entwickler zählen. Storage and Retrieval ist der Job von Datenbanken, darum sollte man sie auch ihren Job machen lassen.
gruß
K-H