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'.