nicht angemeldet
Hallo Hamstar,
LOL - aber nicht, wenn Du auf DBs mit bspw. 50 übelst verzeigerten Tabellen sitzt mit entsprechend komplexem Datenzugriff.
Übelst verzeigert ist natürlich nicht immer ein Qualitätsmerkmal eines DB-Designs ;) aber abgesehen davon ist das eine eher lokale Problematik. Natürlich bedarf es etwas Abstraktionsvermögen, ein brauchbares DB-Design zu entwerfen und komplexe Abfragen zu realisieren. Aber man muss nie über die DB hinausdenken.
Es sind verteilte Systeme.
Die DB ist vielleicht verteilt. Aber was ich meinte, wären Systeme, die bspw. ein Buchhaltung, ein Wahrensystem und eine Fertigungssteuerung verknüpfen. Da hast Du plötzlich mehrere Datenbanken in irgend welchen Teilsystemen, Transaktionssicherheit und Konsistenz der Daten ist nicht mehr im wesentlichen mit "das macht ja die DB" erledigt, und man kann ganz sicher nicht mehr alle Funktionalität in Stored Procedures abhandeln, weil man Abläufe hat, die nicht direkt an irgend welchen Datenbeständen hängen, sondern irgendwo darüber liegen.
Die Navigation macht den Braten nicht fett und somit nicht den Hauptunterschied zur o.g. transaktionalen Datenbankanwendung.
Den GUI-Teil der Anwendung macht sie sehr wohl fett. Deine DB handelt Dir ja maximal den Modell und Funktionalitätsteil Deiner Anwendung ab.
Es ist - wie auch schon an anderer Stelle angeführt - die unterschiedliche "UI-Intensität", die bspw. bei einer Textverarbeitung Komplexität bedingt (und damit wohl auch solche für mich eher lustigen Sachen wie design patterns
Entwurfsmuster sind generell interessant, um saubere OO-Entwürfe zu machen. (Mache davon womöglich sogar für den Entwurf von DB-Designs...).
Wenn man natürlich zwischen HTML-Ausgabe und DB nur ein bisschen Templategefummel oder ähnliches hat, braucht man nicht viel Design. Es gibt aber auch durchaus nicht-GUI-Anwendungen, die komplexer sind, als diese einfachen DB-Anwendungen.
Eine Verwaltungsanwendung, die im wesentlichen Daten abfragt und verändert, ist bezüglich dieses Aspektes eben einfach, weil praktisch keinerlei Berechnungen stattfinden, die organisiert werden müssten.
Sobald viele Infomationsflüsse in der Anwendung realisiert werden müssen, klappt das nicht mehr so einfach. Eine ereignisbasierte Simulationsanwendung wäre dafür ein schönes Beispiel.
Grüße
Daniel