nicht angemeldet
Die Ansätze schliessen einander aus.
Wieso? Was spricht dagegen, SQL zweckmäßig einzusetzen und komplexe Queries evtl. durch Stored Procedures zu ergänzen, ohne gleich alles in der DB abzuhandeln? Gänge Objekt-Relation-Mapper unterstützen diesen Ansatz ja auch.
Wenn ich Hybnerate und ähnliche Tools richtig verstanden habe, dann modelliert man die Logik und Hybernate generiert lauen SQL-Code. Das muss nicht so schlecht sein.
Die prinzipielle Alternative besteht darin alles ausser dem GUI in die DB zu legen.
Ein Mischmasch wäre in meinen Augen die aufwendigste und schlechteste Lösung.
Mag sein, dass das unter ganz besonderen Umständen erforderlich ist, also die Hybnernate-"Hilfe" nicht zu nutzen und alles selbst zu schreiben. Nichtsdestotrotz schliessen sich die Ansätze aus, d.h. wir hätten einen dritten Ansatz, den ich zudem nicht mag.
Vorsicht bei Triggern. Diese Objekte - und das kann nicht oft genug betont werden - haben eigentlich nichts in der DB zu suchen, werden aber für systemfremde Zwecke, bspw. für das controlling, benötigt und sind deshalb im RDBMS implementiert.
Naja man kann die falls notwendig zur Konsistenzsicherung einsetzen (irgendwas löschen, wenn was anderes gelöscht wird).
Genau dagegen sprach ich mich aus. In der Praxis entstehen so debilste Systeme. Wir merken uns: Keine Trigger einsetzen, ausser für controlling Zwecke wie bspw. alerts.
Kann natürlich auch sein, dass man das von einem Objekt-Realtion-Mapper erledigen lassen kann. Diese zwei Ebenen sind auch schwer zu trennen und eher technischer als konzeptioneller Architektur. Eigentlich ist es aus Programmierersicht egal, ob eine DB oder der Mapper irgend etwas erledigt. Das passiert halt irgendwo "unten".
Das sehe ich ganz anders, das ist eben nicht "egal".
Erfahrung bringt es meiner Erfahrung nach sowieso nicht so wahnsinnig, vor allem, wenn man sich im wesentlichen nur mit einem Typ von Software beschäftigt hat... ;-)
Mit dem Typ von SW, die Geschäftslogik nun mal fordert, die Geld bringt so zu sagen. Wir diskutieren hier ja ausdrücklich nicht "SpezialSW" wie bspw. Browser, Grafikprogramme oder Spiele.
Ich rede genau von Deinen 2-Tier Anwendungen. Es gibt da ein Bisschen Datenverwaltung (vielleicht auch ein Bisschen viel Datenverwaltung) und darüber nur noch GUI. Unter Geschäftslogik verstehe ich Arbeitsabläufe, möglicherweise auch Systemübergreifende. Das dürfte der Fall bei den von Dir Angesprochenen "Großsystemen" sein. Natürlich mag man auch in mancher reinen Datenbankanwendung ein bisschen Geschäftslogik in diesem Sinne finden, und deren geringer Umfang mag es rechtfertigen, das nicht rauszuziehen. Ich rede aber von Fällen, in denen die Abläufe selbst eine ernstzunehmende Komplexität erreichen und es nicht nur um die Daten geht.
Du unterliegst dem krassen Missverständnis, dass "VerwaltungsSW" nicht komplex ist. Per se nicht komplex, LOL.
Denke mal darüber nach warum es SW gibt und was diese genau unterstützt.
Danke für den Tipp, ich hab mich schon gelegentlich mit Software und deren Strukturierung beschäftigt.
Als Studi wäre ich da vorsichtiger. ;)