So habe ich das noch gar nicht betrachtet. Wobei ich auch Branchensoftware schreibe/geschrieben habe, aber immer mit der Prämisse: Lass den Kunden so unabhängig wie möglich sein und so flexibel wie möglich. Das ist natürlich kein erfolgreiches Geschäftsmodell, da der Kunde lernt, sich selbst zu helfen.
Eine derartig proprietäre Lösung wurde von mir und meinen Kollegen bzw. anderen Entwicklern und Architekten immer mit einem Facepalm bedacht. Aber da es sie gibt und sie funktionieren, sind sie immer noch 1000x besser als jede Theorie.
Das man ersthaft hinter proprietären Ansätzen steht, ist mir allerdings neu. Sie aus Sachzwängen (Legacy Code) mitzuschleppen.. Nun ja, wer hat keine Leiche im Keller...
Nur: Bitte nicht darstellen als 'gute' Lösung... Man muss in Delphi schließlich auch keine
OOP umsetzen, aber keiner stellt sich hin und propagiert prozedurale Programmierung als echte Alternative. Nur wenn ich legacy software habe, muss ich eben damit leben, das sie so ist, wie sie ist.
Ach #41: Ja, ich hielt meinen etwas ironischen Beitrag für sachdienlich und der Diskussion förderlich. Es tut mir leid, das ich keinen Besenstiel verschluckt habe. Die alten Haudegen, hinter denen echte 30 Jahre Anwenderentwicklung stehen, kann man mit einem Beitrag schließlich nicht verunsichern.
PS: Ich schlage mich hier gerade mit einer Bankingsoftware herum, die entwickelt wurde, bevor Datenbanken frei verfügbar waren (kann man sich nicht vorstellen). Sie sind Weltmarktführer und die Entwickler sollten eigentlich geteert und gefedert werden, aus benannten Gründen (passt also voll zum Thema). So. Sie *sind* Weltmarktführer. Ist damit die Architektur gut? Nein, ist sie nicht. Sie ist grauenhaft. Aber sie ist da.
Da fällt mir immer der alte Spruch ein: "Fresst Sch**se, 1 Mio Fliegen können nicht irren".
View oder nicht View
Ist auch eine Glaubensfrage, die sich allerdings nur dann stellt, wenn es direkte Zugriffe auf die Datenbank gibt. Dieses sollte eigentlich schon aus dem Sicherheitsaspekt vermieden werden. Und wenn alle Zugriffe auf den Datentopf eh durch eine Schicht laufen, dann kann diese Schicht auch die passenden Interpretationen für die einzelnen Konsumenten vornehmen.
Diese Schicht würde sich dann z.B. 'DWH' nennen. In kleineren Anwendungen macht man das aber nicht, sondern geht direkt auf die Daten. Die 'Sicherheit' wird durch Zugriffskontrolle auf Serverebene sichergestellt. Hier einen Appserver zu installieren, würde wieder bedeuten, den einfachen allgemeinen Lösungen wie EXCEL, CrystalReports etc. einen Riegel vorzuschieben.
Bei wirklich großen Anwendungen, die auf eine Reporting-
DB verzichten, gebe ich Dir aber Recht. Meist ist das aber wieder so ein Legacy-Zeugs.
Bei der Diskussion sollte man unterscheiden: "Was *ist* bereits da und funktioniert (aus dem Nähkästchen plaudern)" vs. "Wie sollte man es heute machen"...