nicht angemeldet
Hallo King^Lully,
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.
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). 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".
Ist ja noch blosses brain storming, da sind alle Meinungen hilfreich. "Fast alle Meinungen" war natürlich gemeint.
Ich bin durchaus arrogant genug, meine Meinung auch ohne so umfangreiche Erfahrung als wichtig anzusehen. 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... ;-)
Hast Du schon mal geschrieben sowas, das zeugt von Unverständis bzgl. des Begriffs SW.
»»»» Haha, it depends. Ich vermute, dass Eure Systeme genauso laufen wie die, die ich kenne, d.h. Geschäftslogik und Datenzugriff in den SPs auf dem Datenserver, die DB stellt also ein Gesamtsystem dar, an das nur noch das GUI anzubinden ist. Ich finde solche Systeme gut und leicht pflegbar.
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.
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.
Grüße
Daniel