Moin marabu,
Zitat von
marabu:
wenn du für dein Datenmodell ein
GUI implementiert hast, welches auf datensensitiven Komponenten basiert, dann erschließt sich mir der Sinn der Stored Procedure nicht ohne weiteres. Kannst du das noch ein wenig aufhellen?
Ich will es versuchen. Das Stichwort heißt Flexibität und Wartbarkeit. Denke Dir mal folgendes Szenario:
Eine Artikelverwaltung ist bei unterschiedlichen Kunden im Einsatz. Für jeden Artikel wird z.B. der Verkaufspreis anders kalkuliert. Du hast jetzt die Möglichkeit, diese Berechnungen im Programm fest zu verdrahten. Was macht nun der Kunde, wenn er einen Artikel hinzufügen will? Er müßte jedesmal das Programm anpassen und die Berechnungen einbauen. Und die einzelnen Kunden haben nun auch noch völlig andere Artikel. Das Programm würde zum Moloch werden oder man arbeitet mit kundenspezifischen Versionen. Der Ansatz ist nun, das diese Berechnungen ausgelagert werden. Dafür bietet sich eine
DB wie ORACLE kann. Alles was weitestgehend standard bzw. kundenneutral ist wird über SP in einem Standard-Schema abgehandelt. Alle kundenspezifischen Berechnungen und
DB-Aktionen befinden sich in dem jeweiligen Kundenschema. Kommt also ein neuer Artikel hinzu, werden Preisberechnung und alles andere in einer SP durchgeführt und über reine Parametrisierung dem jeweiligen Artikel zugewiesen. Das ist eine Arbeit von wenigen Stunden bzw. Tagen. Und glaube mir, ich kenne vergleichbare Programme, da ist das Einfügen eines neuen Produkts ein Projekt, daß mindestens über mehrere Monate geht.
Zitat von
marabu:
Zitat von
r_kerber:
Zitat von
marabu:
... Ich würde versuchen die Steuerung vollständig im
GUI zu belassen.
Keine Chance. Das Programm arbeitet grundsätzlich so, daß die
GUI ... zur Steuerung des Ablaufes vorgesehen ist.
Das nenne ich einen Widerspruch.
Sagen wir mal so, die
GUI ist lediglich der Workflow. Alle erforderliche Aktionen (Business-Logik) wird nur angestoßen und in der
DB ausgeführt.