Firebird im profesionellen Umfeld stärker als vermutet ?

[Hansa]

Hi,

seit gestern interessiert mich folgendes : ich habe mir einige Demo-Versionen von ähnlichen Programmen, wie ich sie mache "organisiert". 8) :mrgreen:

Von 4 Programmen benutzen 3 definitiv IB/FB. Bei einem ist es nicht klar. Bei den anderen hat eines die Datenbank mit Endung FDB. Das dürfte wohl Firebird sein. Dann gibt es noch ein 5. bei dem sollen angeblich "Interbase-Schachteln" :mrgreen: da rumgestanden haben.

Deshalb die Frage : wem ist so was auch schon aufgefallen ?

@Mods: ich weiß nicht, ob das jetzt eher nach Klatsch und Tratsch gehört. Wollte hauptsächlich die DB-Spezialisten danach fragen. Von mir aus kann es auch verschoben werden.

[DelphiDeveloper]

was erwartest du an feedback @hansa

ich setze firebird auch oft ein, aber was heißt professionelles umfeld

ab CD Verwaltungsprogramm aufwärts?

Firebird wurde bei mir bei folgenden Projekten eingesetzt

strom/wasser/gas Abrechnungen bei Energieversorger
Branchenlösung medizinischer Bereich
Branchenlösung mit Replikation der Filialen eines führenden Personaldienstleister
Speditionssoftware für eines der größten Spediteure

Insgesamt ca. 8000 Installationen


Ich glaube die größten Vorteile der DB ist die Stabilität und der geringe Wartungsaufwand und natürlich der Preis.


mfg
DD

[Hansa]

Zitat:

Zitat von DelphiDeveloper

was erwartest du an feedback @hansa

Diese Bedenken kamen sofort, als das hier drin stand, aber ich warte mal ab. :mrgreen:

Daniel Magin benutzt ja anscheinend auch am liebsten Interbase. Falls nichts mehr kommt, dann haue ich den in Kassel mal an. Der kommt ja auch viel rum. :mrgreen:

[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.

[mschaefer]

Moin, moin,

bei Inhouseprogrammen habe ich Firebird schon öfters gesehen. Da die Börse in Philadelphia mit interbase laufen soll, dürfte auchder Firebird-Zweig leistungsfähig für größere Umgebungen sein. Allerdings habe ich Sie noch nie bei Mehrstandorteinsätzen mit zentralem Zugriff über Internet
gesehen, bis auf eine Hand voll Firebird-Hoster.

Denke das Firebird übrigens nicht das Problem ist. Ob die vorhandenen Komponenten Industriesicherheit beiten, da bin ich mir nicht ganz im klaren....

Grüße // Martin

[Hansa]

Zitat:

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. :mrgreen: 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.

[Lemmy]

Guten Morgen,

auch ich setze FB im professionellen Umfeld ein: Auftragsmanagement, Dokumentenmanagement,... Ich sehe keinen Grund weshalb das FB nicht können soll.

Zitat:

Zitat von mschaefer

Denke das Firebird übrigens nicht das Problem ist. Ob die vorhandenen Komponenten Industriesicherheit beiten, da bin ich mir nicht ganz im klaren....

Was hat das mit den Komponenten zu tun? Wenn ich ne abgesicherte Verbindung habe (VPN, ....) dann ist es doch wurscht wie auf die Daten zugegriffen wird....

Lemmy

[Thomas Speck]

Mal eine kurze Frage:

Welche Komponenten verwendet ihr zum Zugriff auf Firebird / Interbase ? Benutzt ihr die standardmäßigen IBX-Komponenten oder FIB oder aber evtl. IBO ?

[urs.liska]

Zitat:

Zitat von mschaefer

Moin, moin,

bei Inhouseprogrammen habe ich Firebird schon öfters gesehen. Da die Börse in Philadelphia mit interbase laufen soll, dürfte auchder Firebird-Zweig leistungsfähig für größere Umgebungen sein. Allerdings habe ich Sie noch nie bei Mehrstandorteinsätzen mit zentralem Zugriff über Internet
gesehen, bis auf eine Hand voll Firebird-Hoster.

Denke das Firebird übrigens nicht das Problem ist. Ob die vorhandenen Komponenten Industriesicherheit beiten, da bin ich mir nicht ganz im klaren....

Grüße // Martin

"Professionelle Anwendungen", die mir in diversen Foren über den Weg gelaufen sind:
- Deutsche PresseAgentur (komplette Infrastruktur inkl. aller Zweigstellen und Mitarbeiterlaptops.
- Eine amerikanische Telefongesellschaft, die sämtliche Kunden- und GEsprächsdaten mitFB verwaltet. b
- Irgendein Zweig der amer. Navy ist dabei, ihre gesamten Militärsimulationen von MS SQL auf FB umzustellen.
Auf IBPhoenix.org gibt es eine Reihe von interessanten Fallbeispielen.


Urs

[urs.liska]

Zitat:

Zitat von Thomas Speck

Mal eine kurze Frage:

Welche Komponenten verwendet ihr zum Zugriff auf Firebird / Interbase ? Benutzt ihr die standardmäßigen IBX-Komponenten oder FIB oder aber evtl. IBO ?

IBX wird für Firebird ausdrücklich nicht empfohlen, da sie nur für Interbase gemacht sind und für FB nicht mehr weiterentwickelt werden. Es kann sein, dass man ein Programm für FB 1.5 noch lauffähig bekommt, es kann aber auch nicht sein. Und mit weiteren IB/FB-Versionen wird die Wahrscheinlichkeit noch größer, dass es ernste Kompatibilitätsprobleme gibt.

Verwendet werden wohl hauptsächlich IBObjects, FIBPlus, ZEOS und UIB.
Ich selbst bin gerade am ausprobieren, kann daher noch nichts dazu sagen.
Interessant ist vielleicht, dass es für IBObjects die Möglichkeit gibt, für nicht kommerzielle Verwendung eine kostenlose Lizenz zu beantragen.

Urs

[Jasocul]

Zitat:

Zitat von Hansa

Zitat:

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. :mrgreen: 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. :roll:
Wer das ausdiskutieren möchte, soll dann aber ein PM an mich schicken. Ich mache dann einen Thread auf. :mrgreen:

[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. :lol: 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 ? :shock:

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:

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. :mrgreen: 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. :lol: 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 ? :shock:

[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. :gruebel:
Mag aber auch daran liegen, dass ich keine Software für die Agrarwirtschaft schreibe. :mrgreen:

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...

[MagicAndre1981]

Zitat:

keine Aufteilung auf mehrere Dateien und damit auch keine Aufteilung auf mehrere Platten möglich

Klar kann man eine Interbase/Firebird Datenbank auf mehere Dateien aufteilen. Aber man muss alle Teildatenbanken sichern. Deshalb habe ich bei meinem Firebird-Projekt die Aufteilung selber programmiert (ab bestimmter Anzahl von Datensätzen wird eine neue DB angelegt). In meiner Hauptdatenbank liegt nicht das Bild selbst, sondern nur der Name, der DB in der das Bild gespeichert war.
Mein Sicherungstool schaut dann nur nach, ob man die letzte DB sichern muss, weil sich Daten geändert haben. Es reicht so aus, nur die letzte DB zu sichern.

André

[mschaefer]

Moin Robvert,

schaue Dir mal die Börenskurse von Syngenta an, dann wird klar das man im Agrarbereich Geld verdien kann. 1/3 des Bayer - Umsatzes kommmt aus dem Bereich Agrarbedarfsmittel. Selbst Conti-hat Anteile an Kautschukplantagen und die Agrarbeteiligungen von Néstle.... :zwinker:

[-]
Firebird-Datenbanken können auf zwei Dateien aufgeteilt werden, falls das bei den heutigen Festplatten nötig sein sollte.

[-]
Es kann auch das Führen einer Shadow-Datenbank eingerichtet werden, was Datenverlust aufgrund Festplattenprolbeme verhindern hilft.

[?]
In dem Segment wo FB eingesetzt wird, sind meist nicht mehr als 5 unterschieldiche UserTypen anzutreffen. Oracle kann es natürlich nicht erreichen, aber sonst würde Deine Einschätzung auch auf Windows-XP passen.

[+]
CPU-Auslastung: Bei Datenmengen im Officebereich ist das nicht relevant. Bei größeren Webprojekten ist das korrekt, darin liegt auch der Grund warum Borland interbase hier weiterentwickelt.

[+]
Schemata - ja ist so. Hier würden mich Deine Test´s mit PostGre interessieren.

[+]
Optimizer, das ist wohl so, aber kommt nur bei komplexen SQL´s wirklich zum tragen.


Also so eindeutig ist das letzlich nicht. Ausserdem ist es wichtig bei so Einschätzungen das Arbeitssegment und das Datenbankmanagmentsystem anzugeben, was man als Vergleich nimmt.

@ak1: Nehme Dein Statement als Wissensupdate auf!


Grüße // Martin

[Stevie]

Zitat:

Zitat von Robert_G

@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.

Ok, du bist begeisterter Oracle-Jünger und kannst Firebird nix abgewinnen! :wink: (Achtung, übertriebener Sarkasmus!)
Aber wenn man sich mal anguckt, wer so alles Firebird benutzt (einschließlich der Erfahrungen und Einsatzgebiete),
dann glaub ich kaum, dass die Argumente, die du oben erwähnst, haltbar sind...

[Hansa]

Daß eine Datenbank je nach Bedarf nicht egal ist, das ist wohl klar. 8) Von Internet ist nicht die Rede und hängt nur vom Provider ab. Wenn das nicht geht, dann scheidet Firebird eben aus, aber auch Oracle, M$-SQL usw. Obwohl ich ziemlich sicher bin, daß das da auch bald kommen wird. MySql ist IMHO viel zu schwach. Wenn das US-Militär das einsetzt, dann ist es kaum heikel. Dto. bei Presseagenturen. Durch die embedded Version sind ganz neue Distributions-Möglichkeiten aufgetaucht mit äußerst einfacher "Installation" und und. Das sind schwer schlagbare Argumente für Firebird. Was mir persönlich gut gefällt ist, daß die Neuerungen in 1.5 tatsächlich solche sind, die man braucht. Und was ich von 2.0 und 3.0 lese, dann geht das so weiter. Mit IBexpert hat man ein preisgünstiges Tool auch die DB-Rohdaten zu durchforsten, das kaum Wünsche offen läßt. Und es ist noch aus D (sollte man heutzutage auch nicht ignorieren). Das ist also eine runde Sache.

Aber ich will ja keine Lobeshymne auf IB/FB singen :lol: Habe mir sämtliche Datenbanken angesehen und Interbase war alles in allem eben die beste. Und jetzt Firebird kostet nicht mal was an Gebühren. :shock: Andere haben das aber auch schon gemerkt. :mrgreen:

Zitat:

Zitat von ak1

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

Daß Du das merkst kommt fast zu spät. :mrgreen:

@mschaefer : dein Kommentar kommt um diese Zeit allerdings genau richtig, deshalb sage ich : Mahlzeit :mrgreen:

Und das Thema lautet nach wie vor :

Firebird im profesionellen Umfeld stärker als vermutet ?

[Marcel Gascoyne]

Ich verwende Firebird auch im professinellen Einsatz mit >400 Online Usern ohne Probleme. Wenn man ein Objektframework wie Bold oder Instant Objects einsetzt ist die Datenbank dahinter ja zweitrangig, da diese bei Problemen ohne größere Probleme ausgetauscht werden kann.

Ich kann z.b. bei Instant Objects mit einer XML Datenbank - sprich einem Verzeichnis mit XML Dateien - anfangen. Wenn das nicht mehr reicht stelle ich auf Firebird um. Falls ich hier auch einmal an die Grenzen komme nehme ich halt Oracle. Dabei muss keine Zeile Code der Anwendung geändert werden, da die Abfragesprache nicht SQL sondern IQL (Instant Query Language) ist. Für jeden Datenbanktyp gibt es halt einen Broker der die IQL Befehle in SQL umsetzt.

Gruß,
Marcel