Sicherlich ist ein Datenbankframework in bestimmten Umgebungen durchaus vorteilhaft für die Produktivität bei einer neuen Anwendung, die auf unterschiedlichen Datenbanksystemen laufen soll.
Das hängt aber ja wie bei fast allen anderen Nachrichten hier schon gesagt davon ab, wie fit man damit ist. Ob der Quellcode irgendwann besser lesbar ist für Kollegen, die sich selber erst mal in dieses Framework einarbeiten müssen, halte ich für ein Gerücht, aber noch schlimmer kann es auf der anderen Seite aussehen. Wir haben diverse Kunden, die in mit Ihren Frameworks mehr oder weniger verbunden sind, aber dann am ende trotzdem als
DB immer Firebird ausliefern. Und die von solchen Frameworks erstellten Datenmodelle haben durchaus die Bandbreite von brauchbar bis gruselig. Primärschlüssel sind keineswegs überall Standard, Fremschlüssel schon gar nicht und so manch ein vom Framework generiertes
SQL lässt einen daran zweifeln, das der ursprüngliche Framework Entwickler niemals mehr als 1000 Datensätzen in seinen Tabellen hatte. Wirr in Where Bedingungen auftauchende Upper() Funktionen, die keine passenden Expression Index haben, völlig unsinnige "in" Operatoren mit mehr als 1000 Konstanten, bei der dann im nächsten Schritt zu jedem gefunden Records Einzelsqls abgefragt werden, obwohl man die gesamte Datenmenge schon in einem einzige
sql haben könnte, tragen dabei nicht gerade zur Performanceverbesserung bei. Und ich liebe die Ausrede "das macht unser Framework eben so, da kann ich nichts dran ändern ..."
Es kommt also wirklich drauf an ob Multiplattform wirklich erforderlich ist. Wenn nicht, dann konzentrier dich lieber auf eine Plattform und versuche deren native Sprache mit allen Vor und Nachteilen zu lernen. Wenn ein Kunde dir zwangsweise einen bestimmten Datenbankserver vorschreibt (passiert immer wieder gerne bei
MSSQL Talibans), dann wird der sichelrich auch nicht müde werden, dich für deine vielleicht nicht besonders performanten Abfragen verantwortlich zu machen, ob der ja eigentlich Schuld ist, das du sein Plattform benutzen solltest. Wir haben gerade für einen Kunden eine Schnittstelle zwischen Firebird und
MSSQL realisiert, bei der der Endkunde gar nicht sieht, das die Software eigentlich
MSSQL nur als zusätzlichen Speicher benutzt und die komplette Datenhaltung und Logik in Firebird läuft, der aber nicht mehr so heisst und auch nicht als solcher erkennbar ist, weil wir den als Applicationserver tarnen.
Wir hatten heute gerade bei einem anderen Kunden einen Fall, bei dem wir relativ komplexe Datensätze nach bestimmten fehlenden Detaildatensätzen durchsuchen musst und wenn der fehlte, diesen dann automatisch anlegen. Das war in der Firebird SP Sprache ein Job, der mit einem execute block innnerhalb von 25 Zeilen Quellcode in weniger als 5 Minuten erledigt war, obwohl ca 50000 Records in Frage kamen und ca. 4500 neu angelegt werden musste. Dafür waren aber eben auch gute Kenntnisse der Fähigkeiten von Firebird erforderlich. Theoretisch hätte das auch jeder qualifizierte Programmierer ohne Front End Programmiererfahrung machen können, auch wenn das dann eben nicht 5 minuten sondern vielleicht 5 stunden dauert. Das Know How kannst du aber generell in vielen Plattformen ähnlich nutzen und wenn du mit richtig großen Datenmenge zu tun hast, sind generalisierende Frameworks sehr oft eine Einbahnstraße, aus der du mit vertretbarem Aufwand nicht mehr rauskommst und dir am ende zusätzlich das Know How der jeweiligen Plattform aneignen musst.
Und ob am Ende ein Client auf Basis eines solchen Frameworks auch nur annährend 100000 bis 200000 insert/update/delete/select statements pro Sekunde schafft, was in einer Firebird SP serverseitig problemlos machbar ist, wage ich auch zu bezweifeln.
Und dabei bezieh ich mich explizit nicht auf TMS, ich weiss das Bruno so was nicht nur rausbringt und nach einem Jahr wieder einstellt, sondern wirklich gut weiterentwickelt und guten Support liefert, aber auch damit bist du in seinem ecosystem spricht delphi gefangen. Dein Know How mit so was in der Art ist recht exotisch und kaum woanders benutzbar. Ich brauch Frameworks daher nicht, aber das hast du vermutlich schon vorher erraten.