[Multi-Tier] Architekturfragen / Quellen gesucht

[alzaimar]

Zitat von Elvis:

... möglichst wenige Joins in DB-Abfragen.

Das lässt sich mit komplexen Anwendungen nur schwer vereinbaren, insbesondere, wenn eman mit polymorphen bzw. Metadaten hantiert.

Ich würde eher zu folgender (algemeingültiger) Maxime raten:

Jede Aufgabe wird dem Experten zugewiesen, der dieses Problem am besten lösen kann:

Daten in das DBMS, Logik i.A. in die Mittelschicht. Wobei die 'Logik' zwischen DBMS und Mittelschicht verteilt wird. Oder anders herum: Man sollte DBMS und Logik ('Geschäftsregeln') als einheit betrachten, also Mittelschicht und DBMS logisch zusammenfassen. Innerhalb dieser Entität muss man natürlich deine Grundregeln unbedingt beachten, aber das mit den vielen JOINS lässt sich nunmal nicht immer vereinfachen.

Wir haben gerade sehr erfolgreich einen Cache installiert, der die Datensätze einer VIEW bestehend aus ca. 10-15 Tabellen im Speicher hält und zwischen Mittelschicht und DBMS installiert wird. Er parst das SQL-Statement und schafft es in einem Bruchteil der Zeit, die notwendigen (und zuvor bereits geladenen) Daten aus seinem Cache zu liefern, sodaß wirklich nur neue Datensätze nachgeladen werden müssen (Übrigens ein gutes Beispiel für eine Studienarbeit)

Aber grundsätzlich muß ich Elvis Recht geben: Ein gutes DB-Design ist unumgänglich für effektive und performante Datenzugriffe.

Weiterhin würde ich schon im Ansatz den DB-Zugriff im DBMS so abstrahieren, das nachträgliche Änderungen am Design direkt vorgenommen werden können. Damit meine ich: Für den Zugriff: Views statt Tabellen und Stored Procedures statt INSERT/UPDATE und DELETE. Als Alternative auch die 'updateable Views' und Trigger auf diesen Views.

Ich würde undbedingt eine logische Abstraktionsschicht zwischen DBMS und Mittelschicht und MS und Client vorsehen. Erst damit wird das Teil richtig 'Fett'.