Firebird im profesionellen Umfeld stärker als vermutet ?

[Jasocul]

Zitat von Hansa:

Zitat von ak1:

Firebird wird bei "Demoversionen" oder den günstigsten Versionen aus lizenzrechtlichen Gründen verwendet, da man ja nicht mal einfach so eine Oracle-DB mitliefern kann.

Ist mir zu hoch. Man kann wohl keine FB Demo-Version benutzen, um dann später erklären zu müssen, Oracle sei dafür notwendig und die Konvertierung der bereits eingegebenen Daten koste dann eben läppische 5000 EUR. 8) Und dasselbe nochmals für eine Oracle-Installation.

Das sehe ich genauso.
Hinzu kommt noch, dass dann die Leute offensichtlich keine guten Oracle-Kenner sein können. Erstens werden nicht optimale Komponenten für den Zugriff verwendet und zweitens werd auch sonst nicht auf die Besonderheiten von Oracle eingegangen (-> Optimierung).
Jetzt bin ich bestimmt wieder etlichen auf den Schlips getreten, die meinen, dass man alles so flexibel programmieren muss, dass man mit dem Programm auf jede vorhandene Datenbank zugreifen können muss.
Wer das ausdiskutieren möchte, soll dann aber ein PM an mich schicken. Ich mache dann einen Thread auf.

[lume96]

Moin,

In unserem Geschäften verwenden wir eine Retail-Software der Firma VCS-Timeless (Tochtergesellschaft der englischen Christie-Group).

Diese Retail-Software wurde/wird unter Delphi 7 entwickelt und verwendet mittlerweile Firebird 1.5 (vorher Interbase). Habe jetzt die genauen Zahlen nicht im Kopf, aber weltweit (Europa und China) kommen die auf jeden Fall über 4.000 Terminals (=Kassen). VCS-Timeless ist jedenfalls in Frankreich Marktführer für Retail-Software.

Allerdings wird hier die DB aus Sicherheitsgründen lokal auf jedem Terminal installiert, also kein C/S Schema. Bei mehreren Terminals gibt es Replikationsfunktionen zwischen den verschiedenen DBs.

Die scheinen mit der Wahl der DB ganz zufrieden zu sein (und ich auch; keine grösseren PB die auf die DB zurückzuführen sind).


Tschüss,
Lutz

[Hansa]

Was Oracle betrifft : ich werde den Americas Cup nicht sponsorn. Das mit den Demo Versionen ist aber schon recht lustig. Programm als Demo-Version schreiben, das ja wohl aus naheliegenden Gründen funktionieren muß und dann ein anderes für Oracle ausliefern ? Was soll denn das ?

Was die Zugriffskomponenten betrifft : vor IBX (das ist die Registerkarte "Interbase" ab Delphi Pro) muß man langsam warnen. In FB 1.5 wurden einige wichtige Sachen neu eingeführt. Die NULL Werte können anders bahandelt werden, das Transaction-Management kann SEHR anders sein usw. Die Version 3.0 steht vor der Tür, wobei die 3 kein Schreibfehler ist ! Das sind schon wichtige Dinge. IMHO haben die meisten nicht sehr viel Lust darauf, sich tief in den C-Source einzuarbeiten, um mal nachzusehen was jetzt genau ist. Und ich habe insbesondere keine Lust, ohne es zu merken einen sinnvollen SQL-Befehl zu benutzen, von dem Interbase und somit auch IBX nichts weiß. IBX stellt also mittlerweile ein gewisses Risiko dar.

Und jetzt wieder zu fremden Programmen : interessant sind die Endungen GDB, FDB und IB. GDB kann Interbase und Firebird sein. FDB ist Firebird und IB die kommerzielle IB Version von Borland. Diese Umbenennungen mußten wegen XP gemacht werden. Die Datenbanken auslesen zu können, scheint selten zu gehen. Ich konnte eine DB in IBexpert zwar registrieren, aber Zugriff war nicht möglich.

[ak1]

@Hansa, viele Hersteller von Softwarelösungen preisen ja ihre software damit an, dass diese mit verschiedenen DB-Systemen läuft.
Wenn man nun eine Demoversion zum testen z.B. im Internet bereitstellt, dann bietet sich Firebird an, da es da keine lizenzrechtlichen Probleme gibt. Für Firmen mit schmalem Geldbeutel bietet sich Firebird dann ebenfalls an.
Ich habe mal in einer Firma gearbeitet, welche eine Intranetsoftware vertireben haben, die haben ihre Demoversionen auch mit Firebird angeboten. Das war aber eine Anwendung auf Javabasis.

[mschaefer]

Moin zusammen,

ja das Firebird lizenrrechtlich ideal für den Vertrieb ist, da ist ma sich hier einig.

Das man Datenbanken unter der Applikation problemlos tauschen kann, da sehe ich selbst
bei einem Projekt wie Zeos, wo gerade dies als gestecktes Ziel verfolgt wird, noch große
Probleme.

@urs.liska:
Danke für die Beispiele!


@Lemmy:
Bei den Komponenten gibt es große Unterschiede im Umfang, dem diese dem Anwender Arbeit abnehmen. Mit Zeos kann man sehr flexibel arbeiten, aber man muß beim einfügen von Datensätze erst von Hand die neu generierte ID holen. FIB ist da wesentlich komfortabler, aber auch deutlich spezialisierter auf Firebird. Mit den neuen Zeos-Komponenten und eigenen User-Definied-Functions gibt es auch immer noch Überraschungen. Es bleibt also spannend....

// Martin

[Hansa]

Zitat von ak1:

viele Hersteller von Softwarelösungen preisen ja ihre software damit an, dass diese mit verschiedenen DB-Systemen läuft...

Dann lasse sie das eben anpreisen. So was allgemeines zu schreiben heißt für mich, ein Programm mehrfach zu entwickeln. D.h. nicht nur andere DB, sondern auch : andere Zugriffskomponenten, anderes Admin-Tool, dieselbe Version ist nicht dieselbe. 8) höherer Compilieraufwand usw. Der Wartungsaufwand ist deshalb sehr hoch. Für mich würde so ein Programm schon im Vorfeld aus Kostengründen aussortiert werden.

das ist jetzt aber sehr an den Haaren herbeigezogen :

Ausnahme : zumindest für eine "richtige" Datenbank wie FB : ein Modul läuft nur unter Oracle und anders ist es nicht zu realisieren.

Aber das ist alles Theorie. In der Praxis ist es mir noch nie passiert, daß eine Frage nach der DB gestellt wurde. Geschweige denn, es wurde von der DB abhängig gemacht, das Programm einzusetzen. Die DB interessiert als Enduser keine Sau. Sofern das Programm natürlich funktioniert !

nächste Ausnahme : DB wurde für 50.000 $ irgendwann angeschafft. Jetzt willst du dein Programm dahin verkaufen und es läuft ohne DB-Anschaffungskosten, aber nicht für die gekaufte DB, die dadurch sowieso nicht mehr gebraucht wird. Was sagt jetzt der, der damals die 50.000$ ausgegeben hat ?

[ak1]

@Hansa, es gibt auch Unterschiede zwischen Indiviualsoftware und Standardsoftware. Ebenfalls kann Standardsoftware an Benutzerwünsche angepasst werden. Welche DB verwendet wird interessiert mehr "Säue" als du dir vielleicht vorstellen kannst.
Aber das ist natürlich je nach Kunde und Segment unterschiedlich.

[mschaefer]

Moin, moin,

mit Schweinezyklen wurden ja schon Börsentheorien entwickelt insofern bewegt Ihr Euch ja auf einem interessanten Niveau, aber die Kunden sollten das wohl besser nicht lesen (vielleicht "Edit").

Meine ganz eigene Erfahrung: Hansa hat recht, wenn es um Software ohne Internetanbindung geht. Das System soll laufen und zwar stabil. Was da im Hintergrund arbeitet ist da letzlich nicht relevant.
Ak1´s Auffassung bekommt dann Stellenwert, wenn die Zusammenarbeit mit Webspezialisten gefragt ist.
Dann gibt es meist viel Vorentwicklungen in PHP oder Java und in denen ist es meist aufwendiger die DB zu tauschen als es in Delphi ist.

Fazit: Deswegen lasst man die "Steaks" aussen vor.

// Grüße Martin

[Robert_G]

Ich habe mir noch nie Gedanken darüber gemacht, ob sich irgendwelche Säue für die verwendete DB interessieren.
Mag aber auch daran liegen, dass ich keine Software für die Agrarwirtschaft schreibe.

Ich kann hier Ak1 nur zustimmen. Jasocul hat Recht, solange es sich nur um Delphizugriffe handelt.
Mit ADO.Net oder JDBC sind absolut problemlos DB-unabhängige Zugriffe ohne bremsende Zwischenschicht (ADO, ODBC) möglich.
Wobei man natürlich auf bestimmte Features entweder verzichten muss. Oder man schreibt sich bestimmte Klassen providerabhängig, die dann spezielle Features der DB nutzen.

@Firebird
Wie ich bereits mehrfach schrieb. FB kann ganz nett sein.
Aber es hat auch tierische Patzer, die man einfach nicht ignorieren kann.

• Der Optimizer taugt genausowenig wie der aus Interbase
• Zu hoher CPU-Verbrauch
• keine brauchbare User verwaltung
• keine Schema-unterstützung
• keine Aufteilung auf mehrere Dateien und damit auch keine Aufteilung auf mehrere Platten möglich
• ...

Wenn man weniger als 20 gleichzeitige Sessions fährt und weniger als 100 Tabellen SPs, ... benutzt kommt prima mit FB klar.

Mehr Objekte würden zu scheußlichen Bennenungen führen, da man seine Objekte nicht in einzelne Schemata ablegen kann.
Eins noch: Firebird kann abstürzen oder die Datenbank zerfriemeln. Das macht es für viele Bereiche IMHO zu heikel.

[ak1]

@mschaefer, wie RobertG schon sagte, ist es mit JDBC völlig egal welche DB verwendet wird. Demzufolge ist es im Java-Web-Umfeld auch nicht besonders aufwändig die DB zu "tauschen" (es sei denn man verwendet z.B. oraclespezifische SQL-Funktionen). Wenn man dann noch ein objektrelationales Mapping wie z.B. JDO oder Hibernate verwendet, dann ist es sogar egal ob ich XML-Dateien oder Datenbanken oder... als Datenquelle verwende.

P.S. aber ich komme vom Thema ab...