Hi ewx,
also ich sehe es so:
Wenn ich eine Anwendungstabelle designe und nicht dafür sorge, dass die Datenkonsistenz auch bei Fehlbedienung der Anwendung gewährleistet ist, dann hauen mir das die User nach dem 3 mal gehörig um die Ohren.
Dementsprechend muss ich genausoviel Zeit und Hirnschmalz in den Aufbau der Customizing- als auch der Anwendungstabellen investieren. Mit der Performance meine ich, wenn ich mir hier und da Daten redundant abspeichere bzw. mit Tabellenschlüsseln arbeite, deren Umfang ich kaum noch überschauen kann, dann geht mir die Performance ab einer bestimmten Anzahl Datensätzen definitiv in den Keller. Und dann kommen wieder die User...
Will sagen: Für mich als ehemaligen Entwickler und jetzigen Fachgruppler ist das Design der Tabellen wichtiger als die Frage wer was pflegt und der Inhalt der Tabellen. Wenn ich beim Design schlafe, egal wo, wird meine Anwendung Sch***e, sei es durch fehlende Flexibilität oder durch schlechte Performance.
Wer dann letztendlich wo was pflegt, ist im Grunde genommen organisatorisch bedingt. In kleinen Unternehmen ist sowas oftmals in der gleichen Hand, im Mittelstand und Konzernen ist das meist aufgeteilt.
Bsp. bei uns:
1. Entwickler designed C und A-Tabellen, testet die Anwendung technisch
2. IT Fachgruppe pflegt C-Tabellen, testet Anwendung fachlich
3. Fachabteilung pflegt indirekt über die Anwendung die A-Tabellen und motzt bei Fehlern 2. an, die motzen dann 1. an.
Allerdings habt Ihr ja meiner Meinung nach mehr den Inhalt der Tabellen betrachtet, und da ist sicherlich für den Ablauf der Anwendung das Customizing interessanter obwohl auch vom DB-Stand in den Anwednungstabellen abhängt, "wo die Anwendung langläuft."