nicht angemeldet
Genau da gibt es ja die zwei Konzepte "Alles in der DB" und "die DB ist nur ein dummer Storage von Daten".
Beide Ansätze sind meiner Meinung nach falsch, die Lösung liegt wie meistens irgendwo in der Mitte ;-)
Die Ansätze schliessen einander aus.
Klar, aber so gigantisch ist ja die Funktionalität die man in der DB haben sollte nicht. Es geht eigentlich nur um die sinnvolle Verwendung von Queries und evtl. einige Stored Procedures um diese zu ergänzen und evtl. um die Daten konsistent zu halten (Trigger etc).
Vorsicht bei Triggern. Diese Objekte - und das kann nicht oft genug betont werden - haben eigentlich nichts in der DB zu suchen, werden aber für systemfremde Zwecke, bspw. für das controlling, benötigt und sind deshalb im RDBMS implementiert.
Ein Zeil des Redesigns unserer Software ist es eben auch, dass wir schlagkräftiger bei der Umsetzung von Kundenprojekten und den damit verbundenen Anpassungen werden.
Dazu kann man nicht viel sagen, ohne das Datenmodell zu kennen.
Genau, das ist der Knackpunkt, welche "Kundenprojekte" generieren warum Komplexität? Eventuell gibt es da ganz andere Lösungen als die bisher angedachten.
Ich hab' nicht viel praktische Erfahrung (studiere noch) ich betrachte das also alles eher von außen.
Ist ja noch blosses brain storming, da sind alle Meinungen hilfreich. "Fast alle Meinungen" war natürlich gemeint.
Es gibt aber nach meinem Eindruck eine gewisse Klasse von Verwaltungsanwendungen, die im Wesentlichen Daten erfassen und Daten anzeigen. Eine eigentliche Anwendungslogik gibt es da praktisch nicht.
Hast Du schon mal geschrieben sowas, das zeugt von Unverständis bzgl. des Begriffs SW. Denke mal darüber nach warum es SW gibt und was diese genau unterstützt. BTW - SW ist (auch konzeptionell) etwas ganz anderes als das was im Wilden Westen SW war.