-Müssen bei Mehrschichtenarchitektur primary und foreign keys
GUID sein? (Ich hasse
GUID, sie sind schlecht lesbar, können nicht chronologisch sortiert werden und werden von den
DBMS Systemen deutlich langsamer angesprochen.
-Darf ich in der Datenbank keine Referenzielle Integrität mehr einsetzen? (Die Mittelschicht soll angeblich der Herrscher für die Geschäftslogik sein. RefInt. Hat mir schon mal den A.. gerettet weil ich übersehen habe das ein Datensatz bereits verwendet wurde und ich es löschen wollte.)
zu 1: nein, Multitier geht auch ohne
GUID - IDs. (Sie haben aber auch Vorteile, wie zum Beispiel, dass sie praktisch keine Mengenbegrenzung haben, dass man Objekte über eine HashMap typunabhängig in einem Cache ablegen kann, und dass man sie clientseitig ohne Kollisionsgefahr erzeugen kann). Hinsichtlich Performance: ja, wenn man täglich Terabytes bewegt, können sie durchaus nachteilig sein
zu 2: doch, man 'muss' natürlich immer RI verwenden. Nur weil man einen Teil der Anwendung in eine andere Softwareschicht legt, heisst nicht das diese wie ein Staubsauger auch alle Logik aus der Datenspeicherungsschicht abziehen muss. Bei Triggern und Stored Procedures ergibt sich allerdings schon ein Migrationseffekt - vieles was man früher aus Performance- oder Sicherheitsgründen in der Datenbank ablegte, kann man in die mittlere Schicht verlagern. Damit ist eine dreischichtige Architektur of auch leichter änderbar als eine zweischichtige (Stichwort "Datenbankmetadatenänderung nur mit Unterschrift der GL").