Die Argumente:
Ich bin Entwickler, Firebird Nutzer, und sehe bestimmte Defizite bei der Implementierung der Datenbank
Ich bin Berater, Firebird Fachmann und sehe bestimmte Defizite bei der Nutzung bzw. dem Entwickler-KnowHow
Ich bin Entwickler, Firebird Nutzer, Berater, und Firebird Fachmann und sehe bestimmte Defizite bei der Nutzung bzw. dem Entwickler-KnowHow, aber auch bestimmte Defizite bei der Implementierung der Datenbank.
So seh ich das, das eine widerspricht dem anderen nicht und auch keineswegs den Erkenntnissen der vorherigen Beiträge anderer Autoren.
Und bewahrt mich davor, das mir irgendjemand irgendeinen 20 Jahre alten Delphi/Interbase Code von mir unter die Nase hält und sagt, modernisiere das mal bitte eben nach deinen aktuellen Erkenntnissen. Aber es gibt eben sehr große Unterschiede in meinen Projekten von vor 20 Jahren und der generellen Architektur, mit der ich heute meine Software aufbaue. Vor 25 Jahren war der Weg auch in meinen Augen super, weil man unglaublich schnell zum funktionierenden Prototypen kam. Das lief aber schon sehr schnell an Grenzen, die mich zwangen, vieles zu hinterfragen.
Da ich in den letzten 25 Jahren eben auch oft als externer Softwarearchitekt bei mehrjährigen Projekten gebucht wurde (meistens für 40-80 Tage pro Jahr) und dort mit entsprechenden Teams, bestehend aus Mitarbeitern des Kunden, die Möglichkeit hatte, immer wieder Projekte komplett neu aufzubauen und den immer wieder einen neuen Stempel aufzudrücken, war es für mich immer ein guter Weg, meine Kenntnisse aus der vorherigen Projekt zu verbessern und für die erkannten Probleme neue Lösungsstrategien aufzubauen. Diesen Vorteil haben die meisten Entwickler in Ihren Angestelltenverhältnissen leider meistens nicht, sondern sind vom eigenen Projekt oder den Vorgaben der Unternehmensleitung im System gefangen.
Wir sind übrigens in Berlin auf der Firebird Konferenz auch mit dabei