Hi!

Ich entwickle momentan 2 Programme gleichzeitig: eine große Applikation und ein kleines Hilfsprogramm. Beide sind unabhängig voneinander, benötigen aber eine Datenbank. Für das große Programm ist die Entscheidung schon für Interbase gefallen und wir haben auch schon Lizenzen gekauft. Da wir das kleine Programm relativ preisgünstig anbieten wollen, wollen wir kein Geld für DB Lizenzen ausgeben - zumal keine großartigen Anforderungen an die Datenbank gestellt werden.

Ich würde für das kleine Hilfsprogramm ja gerne Firebird einsetzen, bin mir aber nicht sicher, ob ich beim Entwickeln nicht Probleme bekomme, weil ich ja schon Interbase installiert habe. Daher meine Fragen:

1.) Wer hat Erfahrung mit Parallel-Installation von Firebird und Interbase und kann mir Näheres berichten?
2.) Kann ich für Firebird dieselben Interbase Express (IBX) Koponenten wie für Interbase einsetzen?

Vielen Dank im Voraus!

dirkil2 hat folgendes geschrieben:

Hi! Ich entwickle momentan 2 Programme gleichzeitig: eine große Applikation und ein kleines Hilfsprogramm. Beide sind unabhängig voneinander, benötigen aber eine Datenbank. Für das große Programm ist die Entscheidung schon für Interbase gefallen und wir haben auch schon Lizenzen gekauft. Ich würde für das kleine Hilfsprogramm ja gerne Firebird einsetzen...

Den Rest zitiere ich erst gar nicht. Wer ist dafür verantwortlich, sich diese Informationen erst jetzt zu beschaffen ? Parallelentwicklung auf fast ein und derselben Datenbank ? Und ob das "kleine" Programm besser läuft als das "große" auf dem Stiefkind Borland-Interbase wage ich zu bezweifeln. Aber es gibt wohl schon Gründe dafür, so etwas zu machen. *fired*

Um es zum Thema kurz zu machen : sofern du nicht alle "features" einsetzt, die nicht total inkompatibel sind, dann geht das schon. Aber es geht schon noch weiter : IBX und FB geht wohl, aber wie lange noch ? Und dann gehts los: IBX für IB was anderes für FB. Das Rad wird also doch zweimal erfunden. Ich habe wegen Delphi immer Interbase auf der Kiste neben FB. Die falsche GDS32.DLL wäre fatal. Genauso wie die Administration usw.

Du kannst nicht auf einer Maschine gleichzeitig FB und IB laufen lassen, es geht nur entweder oder. Denn da die beiden vom selben abstammen, verwenden sie den gleichen Port und das gleiche Protokoll.

Also ihr solltet Euch schon entscheiden. Eine Möglichkeit wäre es z.B. (wenn ihr nur eine Maschine für den Server habt) beides auf Interbase/Firebird zu entwickeln und auf dem jeweiligen anderen dann zu testen. So wäre sogar eine übergreifende Kompatibilität möglich.

IBX funktioniert immer noch wunderbar mit FB 1.5, solange man nicht die administrativen Komponenten verwenden muss.

Und ihr solltet eventuell schauen, auf welchen Server Systemen die Datenbank laufen soll, da die frei Version, also die Interbase 6 auf Win2003 Server Systemen bzw. Systemen mit Hyperthreading schwierigkeiten mit den Zugriffen hat.

Also Interbase 6 würde ich inzwischen nicht mehr verwenden. Wenn dann FB 1.5 oder die kostenpflichtige IB-Version. Mit der 6er hatte ich auch Probleme, dann bin ich auf FB umgestiegen und es lief ohne Probleme (vor alle Stored Procedures). Der läuft auch gut unter Win2003.

Kannst du mir noch sagen ob die backup und restore funktion beim FB 1.5 funktioniert, die ist ja in der IB 6 mal voll.. nicht so toll.

Warum sollen die nicht gehen ? Gestern gingen sie noch.

Damit gibt es bei mir immer Schwierigkeiten, da die Tabellenstruktur falsch wiedergegeben wird, und Trigger oder Stored Procs falsch eingelesen werden.
Darum frag ich, ich kenns nicht anderst, erst mit dem Interbase 7 funktioniert das bei mir einwandfrei.

UGrohne hat folgendes geschrieben:

Du kannst nicht auf einer Maschine gleichzeitig FB und IB laufen lassen, es geht nur entweder oder. Denn da die beiden vom selben abstammen, verwenden sie den gleichen Port und das gleiche Protokoll.

Hallo!

Irgendwo habe ich gelesen, daß du bei FB den Port umknipsen kannst, sodaß sie sich nicht in die Quere kommen. Ich habe es selber noch nicht gemacht, aber zumindest ist in der conf-Datei tatsächlich auch ein Eintrag für die Portangabe vorhanden.

Cu,
Udontknow

Man kann auch Firebird embedded (Einzelplatz) verwenden. Aber wie gesagt, ich sehe den Sinn nicht, was das alles soll. Momentan sind die Unterschiede nicht so gewaltig. Außer eben beim Preis.

Hi,

es sollte keine Probleme bereiten, IB und FB paralell auf einem Rechner zu betreiben.
1. Ab Fb 1.5 (was man einsetzen sollte) heißt die Client-Bibliothek anders
2. Ab 1.0.x sucht sich FB den Port eigenständig (den konnte man aber auch schon früher manuell umlenken)
3. Ab 1.5 heißt der Server anders.

Die Opensourcevariante von Interbase würde ich aber unter KEINEN Umständen mehr einsetzen, da ist FB die erste Wahl. Soll evtl die IB 7.x eingesetzt werden zum Testen auf alle Fälle ne aktuelle Version verwenden!
Grüße
Lemmy

Hallo,

du kannst die *.fdb (FB-Datenbankdateien) und "normale" Interbase-DB-Dateien erstellen und auf beide mit der Firebird-Engine zugreifen.
Für den Zugriff auf FB würde ich die ZEOS-Komponenten (www.sourceforge.net) verwenden.

Allgemein dazu aber: Wir haben vor der Auswahl einer DB SEEEEHR viele Performance-Tests gemacht (natürlich hauptsächlich für unsere konkrete DB-Struktur). Dabei hat sich gezeigt: Auf einem "Durchschnittsrechner" (2GHz, IDE-Platte, 512MB Ram) nehmen sich:

Oracle, Firebird (1.5), Interbase 7, MS-SQL FAST NICHTS !

Oracle bringt nur etwas auf superteuren (dual XEON, 7 SCSI-Platten o.ä.) Rechnern,
FB und Interbase sind sich auf fast jedem Rechner ebenbürtig,
MS-SQL kann wenig für viel Geld (aber der Enterprise-Manager ist geil )

MySQL... lassen wir das

FAZIT: Wozu Interbase ?

Viele Grüsse.

P.S.: Damit niemand denkt, ja die mit ihrer 10-Tabellen-DB-Architektur und 10 Mann die drauf zugreifen...
Wir haben 182 Tabellen, in einigen mehr als 100.000.000 Datensätze und 400 Clients. Das ganze läuft auf Oracle.
Wir haben es allerdings mit Interbase probiert (*keine*Chance*), daher sagt das nichts über die Konkurrenz Firebird aus !

recall hat folgendes geschrieben:

...MS-SQL kann wenig für viel Geld ...FAZIT: Wozu Interbase ? ... Wir haben es allerdings mit Interbase probiert (*keine*Chance*), daher sagt das nichts über die Konkurrenz Firebird aus !

Dolche Behauptungen mußt du aber schon etwas näher begründen.

1. was kann MS-SQL wenig ? Bzw. was fehlt / ist schlecht.
2. das ist wohl bezogen auf die Alternative Firebird ? Dann wäre es schon klar.
3. was heißt "(*keine*Chance*)"

Vor allem letzteres. Mir ist nämlich ein Projekt bekannt mit ähnlicher Größenordnung. 400 User usw. Die machen das mit Firebird und sind voll zufrieden. Ich habe hier lediglich ca. 50 Tabellen und ca. max. 100 MB Datenbank FB und sehe keine Performance oder sonstige Probleme.

Zitat:

1. was kann MS-SQL wenig ? Bzw. was fehlt / ist schlecht.

Naja, es kann eben nicht viel mehr als Firebird, kostet aber Unmengen .
Es fehlt nichts in dem Sinne, nur ist es halt meiner Meinung nach überteuert. Oracle hat mit 10g das Grid-Computing und hätte somit noch ein Argument (naja und vll. noch die bessere 2-Prozessor-Architektur-Unterstützung) für den horrenden Preis

Zitat:

2. das ist wohl bezogen auf die Alternative Firebird ? Dann wäre es schon klar.

s.o.

Zitat:

3. was heißt "(*keine*Chance*)"

Dazu muss man wissen: Es ist ein Programm zum ECHTZEIT-abrufen von Messdaten, d.h. aber auch, dass sehr viele Daten bereits per Stored-Procs aufwändig vorbearbeitet werden. Somit ging das ganze nur per Grid-Computing zu realisieren (eben 10g). Da FB/IB das nicht unterstützt: (*keine*Chance*). Das war aber nur als Anmerkung gedacht, damit sich keiner denkt: Aha der redet wie toll FB ist, aber selber setzt er Oracle ein (?!). Ich wollte nur sagen, dass die Tatsache, dass wir Oracle einsetzen für den Vergleich von FB und IB nicht relevant ist.

Viele Grüsse.

Aha. Aber was verstehst du unter Grid-Computing ? Meinst du die Multiprozessor Geschichten, oder was ? Und noch eine Frage an einen Oracle Mann : hättet ihr Oracle auch verwendet, wenn es nicht ausgerechnet um Meßdaten ginge ?

Zur Preisgestaltung : sehe ich genauso. In M$-SQL sehe ich keinen Vorteil gebenüber IB/FB. Und Oracle ist wirklich nur was für Riesen-Anwendungen. Wie die bei euch. Deshalb völlig ungeeignet für ein Programm, daß man für 1-100 Plätze entwickeln muß, bzw. an völlig verschiedene Kunden verkaufen will. Allerdings scheint sich da auch etwas getan zu haben, denn ein Freund von mir hat ein Logistik-Programm auf Oracle aufgebaut und zwar wegen des Preises. Er sagt, Interbase wäre im Endeffekt genauso teuer gewesen, wie Oracle. Da gehts auch um viele Clients. Nun ja, bei einem Preis von ca. 75$ für Borland Workstation Lizenz kann ichs fast nicht glauben. Wenn Oracle halt etwas wichtiges hat und die anderen nicht, dann ist der Preis ja gerechtfertigt. Aber eben nur wenn es unverzichtbar ist.

Und hier zum Hauptthema : entweder IB oder FB. Alles andere macht keinen wirklichen Sinn.

grid-computing ist DIE Neuerung schlechthin
Denn damit kannst du eine Datenbank auf mehrere Server verteilen (wir haben derer 4) ! Für weniger als unser Projekt hätten wir unter Garantie Firebird eingesetzt. Oracle und MS-SQL machen jedoch manchmal Sinn, wenn man kompatibel bleiben will (Beispiel Navision oder SAP !) oder wenn man den Kunden mit "bekannten" Namen locken will. Interbase kennt sowieso kein Schwein, und wer es kennt, der ist Alternativen von vornherein nicht abgeneigt, so dass ich Firebird immer bevorzugen würde, denn das ist 100% gratis und WIRKLICH GENAUSO GUT.

Viele Grüsse.

Hier gibt es weitere Infos zur Koexistenz von Firebird und IB: firebird.sourceforge...manual/ibfbcoex.html