Datenbanklogik

[gfoidl]

Hallo liebes Forum!

Ich überlege gerade wieviel Logik ich auf die Datenbank (Stored Procedures, Trigger, etc.) oder dem Client verlagere. Grundsätzlich könnte nur der Client die Logik ausführen, aber warum sollen nicht die Features des Datenbank-Servers genutz werden.

Was ist eure Meinung dazu?

mfG gü

[Bernhard Geyer]

Es wird keine allgemeine optimale Lösung geben. Dazu spielen noch andere Aspekte wie:

- DB-Unabhängigkeit (SP/Trigger müssen für jedes DBMS extra entwickelt werden).
- Mehrschichtige Architektur (wieso aufwändig bzw. teilweise kompliziert in die DB verlagern wenn es der Business-Layer einfacher kann).

[Falk Prüfer]

Das ist eine Frage wegen der sich ganz schnell die Gemüter erhitzen können .
Zu "Fat Server vs. Fat Client" gibt es durchaus kontroverse Meinungen. Im Endeffekt solltest du überlegen wo dein Schwerpunkt liegt. Möchtest du eine Datenbank die von unterschiedlichen Frontends relativ einfach bedient werden soll (Desktop-Anwendung, Web-Frontend, Mobile Schnittstelle, etc.), dann geht die Tendenz eher zum Fat Server, um nicht in jedem Frontend alles neu coden zu müssen.
Ist der grundlegende Ansatz eher EINE Applikation, die möglichst auf verschiedenen DBMS laufen soll, dann wird es wohl eher ein Fat Client, um - wie von Bernhard schon gesagt - den Aufwand für die unterschiedlichen DBMS in Grenzen zu halten.

Gruß Falk

[gfoidl]

Danke für eure Antworten!

Ich persönlich bevorzuge eher die Logik auf dem Server, da ich den Wartungsaufwand für Frontends minimieren will.

Bezüglich meiner Frage wollte/will ich eure Meinung dazu wissen, vielleicht gibt es ja einen Aspekt der meine Überlegung zu Fat-Server und Fat-Client ändert und/oder erweitert.

Danke nochmals.

mfG Gü