Befindet sich jedoch die Geschäftslogik (oder auch nur Teile davon) in der Datenbank, kann es schonmal "sportlich" werden.
"Sportlich" wird es m.E. vor allem dann, wenn Teile der Geschäftslogik irgendwo liegen.
Die Geschäftslogik sollte ein Ganzes sein und nicht irgendwo verstreut. Ein Server ist ein Server ist ein Server usw.
Eine Entschuldigung für die Aufteilung von Geschäftslogik ist allenfalls, wenn diese Aufteilung kongruent zu den Logikbereichen ist, die der jeweilige Teil bedient. Also 2 Server, 2 Zuständigkeitsbereiche usw.
Wir haben eine Anwendung, die die gesamte Geschäftslogik in der Datenbank hält. Sehr unsportlich. Nein, Spaß. Eignet sich super für heterogene Clientlandschaften inkl. verschiedener Webserver Anbindungen. Alles nur noch "dumme" Clients, also etwas netter formuliert reine Visualsierung.
@Jobo:
Du beschreibst eigentlich genau das, was ich meine:
entweder <-> oder.
Logik in der Datenbank: Es ist egal, was für ein Client genutzt wird. Die Logik zieht immer.
Heißt aber auch: Immer die gleiche Datenbank und nicht bei einem Kunden diese und beim nächsten Kunden jene und dann könnten wir auch noch "sonne oder solche" Datenbanken nehmen ...
Übertrieben formuliert. Logik in der Datenbank: andere Datenbank -> neue Implementierung.
Die Logik liegt in der Applikation: Dann nur diese Applikation und sonst niemand.
Ein bisserl Logik in der Datenbank und die "Reste" in N Applikationen? NoGo
Wer sowas entwirft, empfiehlt ... gehört gehauen
