IBX oder ZEOS

[Andy Nightingale]

Hallo Leute,
hat jemand Erfahrung mit IBX und Firebird? Habe gelesen das IBX schneller wäre. Hat jemand Erfahrung mit IBX?
Grüße

[charlytango]

Mittlerweile wissen schon viele dass Firebird und ich keine besonderen Freunde sind.

Trotzdem eine allgemeine Überlegung abseits von solchen persönlichen Vorlieben.
IBX ist meines Wissens nur auf Firebird ausgerichtet.
Das wäre mir auch bei einem Geschwindigkeitsvorteil einfach zu heiss.

Meine Strategie bei SQL Datenbanken ist es, sie möglichst austauschbar zu machen, dass das Programm mit jeder SQL Datenbank läuft die zumindest SQL92 kompatibel ist.
Ich gehe sogar so weit dass ich in meinem Datenbank-Zugriffsobjekt zwischen SQLDB und ZEOS per DEFINE umschalten kann.

@af0815 wird einwenden, dass man bei Verwendung von Server-spezifischen SQL Statements das alles vergessen kann. Stimmt. Ich habe es bisher geschafft, solche Statements ebenfalls mit DEFINE zu kapseln oder in eine eigene Unit zu schieben, die man bei Bedarf mit vertretbarem Aufwand anpassen kann. Die allermeisten Statements die man in einer Businessapplikation braucht sind DrillDown - also von einer Übersichtsliste bzw einem Suchergebnis in die Tiefe. Und das läuft über Primary und Foreign Keys. Das kann jede DB.

Anders formuliert: Flexibilität ist mir wichtiger als Tempo (das im übrigen durch gute Indexierung mehr beeinflusst wird als durch eine angepasste Treiberschicht)

[af0815]

Ich wende da nichts ein Kurze Test Anwendung schreiben und ein paar Speedtest machen.
Ob man das auf eine DB hin macht, muss man aus dem Anwendungsfall entscheiden. Wenn der Kunde bereits eine Serverfarm hat, dann spricht nichts dagegen die DB Verbindung auf das zu optimieren.

In einem weltumspannenden Konzern wo ich gearbeitet habe, war die einzige Wahrheit MS SQL. Daher alles auf die Server Type hin optimiert. Weil wenn der Kunde den Servertyp wechselt, hat er nicht nur die Programme von mir als Herausforderung.

Nur gegen den Strom schwimmen, sollte man sich gut überlegen.

Also spricht nichts gegen IBX. Zeos und SQL DB sind ja auch da. Mit IBX gehen halt die Dinge nativer, dafür wirst du hier vermutlich weniger Support bekommen, weil das IMHO mehr eine Nischenprodukt ist.

[Andy Nightingale]

Also spricht nichts gegen IBX. Zeos und SQL DB sind ja auch da. Mit IBX gehen halt die Dinge nativer, dafür wirst du hier vermutlich weniger Support bekommen, weil das IMHO mehr eine Nischenprodukt ist.

Danke 0815 für die Einschätzung

[Zvoni]

Kenne weder IBX noch ZEOS.
SQLdb hat mir bisher immer vollkommen ausgereicht.

Ich stimme da Charly zu: Ich versuche meinen DataAccess-Layer auch immer so allgemein wie möglich zu halten.

Aber die Aussage "IBX ist schneller" bezweifle ich irgendwie.
Bzw. die Speed-Unterschiede dürften eher minimal sein (bei gleichen Daten-Voraussetzungen).

Die grössten Performance-Gewinne findet man eher bei der Formulierung der SQL-Statements, dem "Design" der Tabellen (Charly hat ja schon Indizes erwähnt) bzw. bei Server-basierten DB's in der Server-Config.

Und was das hier betrifft:

.....wird einwenden, dass man bei Verwendung von Server-spezifischen SQL Statements das alles vergessen kann. Stimmt. Ich habe es bisher geschafft, solche Statements ebenfalls mit DEFINE zu kapseln oder in eine eigene Unit zu schieben, die man bei Bedarf mit vertretbarem Aufwand anpassen kann.

Selbst Schuld.
In meinen DB-Anwendungen gibts genau ein einziges hart-codiertes SQL-Statement im Quell-Code des Frontends:

Code: Alles auswählen

SELECT SQLStatement FROM tbl_sql_statements WHERE ID=:pID;

Und dieses Statement versteht so ziemlich jede SQL-Datenbank auf der Welt.

Der Rest sind numerische Konstanten, welche die ID's der eigentlichen Statements sind.
Ich speicher die eigentlichen (DB-Spezifischen Statements!!) in der Datenbank selbst in einer eigenen Tabelle.
Ich muss nur für den Erststart dann einen SQL-Dump dieser Statement-Tabelle (Textdatei) vorhalten (wie auch aller anderen Tabellen).

Da ich den eigentlichen Data-Access-Layer in eine Library/DLL kapsle (Im Prinzip alles was mit TSQLConnection zu tun hat), muss ich bei DB-Wechsel nur eine neue Lib/DLL schreiben, da die Lib dynamisch per LoadLibrary geladen wird, und ein "normiertes" Interface nach aussen anbietet

Es erfolgt ein Wechsel von SQLite nach MySQL? Kein Problem.
MySQL-Access-Lib schreiben, SQL-Statements spezifisch formulieren, in die DB ballern (gleiche ID's!!), Feuer frei.
Muss das Frontend nicht mal neu kompilieren

[Andy Nightingale]

Kenne weder IBX noch ZEOS.
SQLdb hat mir bisher immer vollkommen ausgereicht.

Ich stimme da Charly zu: Ich versuche meinen DataAccess-Layer auch immer so allgemein wie möglich zu halten.

Es erfolgt ein Wechsel von SQLite nach MySQL? Kein Problem.
MySQL-Access-Lib schreiben, SQL-Statements spezifisch formulieren, in die DB ballern (gleiche ID's!!), Feuer frei.
Muss das Frontend nicht mal neu kompilieren

Hallo Zvoni,
eine Verständnisfrage. Warum? Ich meine ich habe diesen neuen Kunden und der möchte das alles auf Firebird.-weil es anscheinend Vorschrift ist. Nun ich habe Ihm gesagt das die meisten Programmierer dies auf MySQL usw. haben.-die Antwort war: Es wird nur Firebird akzeptiert aus folgenden Gründen bekam dann eine Übersicht dazu.

[Zvoni]

Du hast das missverstanden:
Wenn du eine Vorgabe vom Kunden hast, dann hast du eine Vorgabe vom Kunden. Punkt!
Braucht nicht weiter darüber diskuttiert werden.

ABER: FireBird ist OpenSource und ein "freiwilliges" Projekt.
Du hast keine Garantie, dass es für die nächsten 20 Jahre weiter entwickelt wird.

Wenn jetzt in 10 Jahren die Nachricht kommt "FireBird wurde beerdigt",
und dein Kunde sagt: "Hmm.... OK, jetzt müssen wir wohl oder übel auf MySQL oder PostGres wechseln"
-->, was dann?
Willst du (mehr oder weniger) wieder bei Null anfangen?

Ich sage NICHT, dass du es so machen sollst, wie ich es mache.
Es ist dein Kunde, und es ist deine Software.

Ich möchte dir nur einen Gedanken-Anstoss geben "Was wäre wenn...."

Ich weiss nicht mehr, wer es geschrieben hat (ich glaube es war af0815):
"Unser Kunde hat gesagt MS SQL und nichts anderes"
hat seine Gründe --> Support!!

Wie heisst es so schön: Prophylaxe ist besser als Behandlung

[af0815]

Wenn der Kunde in 10 Jahren andere Vorstellungen hat, ist es ok alles neu zu überdenken. Projekte werden jetzt gemacht. Und die Syntax am Server ist jetzt gültig. Da denke ich nicht so flexibel. Weil ich habe gesehen, was sich in ein paar Generationen am MSSql geändert hat. ZB. Pivots sind jetzt Standard, früher eine Herausforderung. Jetzt denken und womöglich optimal umsetzen. Aber nicht, was wäre wenn in 10 Jahren denken. Zahlt dir heutzutage kein Schwein.

[LazarusFuchs]

"ABER: FireBird ist OpenSource und ein "freiwilliges" Projekt.
Du hast keine Garantie, dass es für die nächsten 20 Jahre weiter entwickelt wird."

Die Aussage ist richtig, es ist aber folgendes zu bedenken:

Das gilt auch für alle anderen, egal ob OpenSource oder Kommerz Software.
Bei OpenSource haben sich sehr oft Entwickler gefunden die das Projekt weiterführten.

Firebird ist meiner Meinung nach mittlerweile so häufig und auch
bei großen Firmen und Organisationen im Einsatz dass die
Gefahr der Einstellung der Weiterentwicklung sehr gering ist.

Außerdem hat Firebird ein Alleinstellungsmerkmal, das nicht
zu unterschätzen ist - es kann ohne Serverbetrieb (Embedded)
laufen als auch auf einem Server mit, soweit ich das erörtern
konnte, mit hunderten Clients - mit der gleichen Software.

Ausgeschlossen ist eine Einstellung nie, bei keinem einzigen Produkt
bzw. bei keiner einzigen Software.

[Zvoni]

"ABER: FireBird ist OpenSource und ein "freiwilliges" Projekt.
Du hast keine Garantie, dass es für die nächsten 20 Jahre weiter entwickelt wird."

Die Aussage ist richtig, es ist aber folgendes zu bedenken:

Das gilt auch für alle anderen, egal ob OpenSource oder Kommerz Software.
Bei OpenSource haben sich sehr oft Entwickler gefunden die das Projekt weiterführten.

Firebird ist meiner Meinung nach mittlerweile so häufig und auch
bei großen Firmen und Organisationen im Einsatz dass die
Gefahr der Einstellung der Weiterentwicklung sehr gering ist.

Außerdem hat Firebird ein Alleinstellungsmerkmal, das nicht
zu unterschätzen ist - es kann ohne Serverbetrieb (Embedded)
laufen als auch auf einem Server mit, soweit ich das erörtern
konnte, mit hunderten Clients - mit der gleichen Software.

Ausgeschlossen ist eine Einstellung nie, bei keinem einzigen Produkt
bzw. bei keiner einzigen Software.

Auch wiederum korrekt. Hab ich jetzt nicht wirklich berücksichtigt, da ich mit Firebird null Berührungspunkte habe.

Andererseits braucht man nur mal verfolgen, was zur Zeit mit Manjaro passiert.

Aber mir ist gestern Abend der "berüchtigste" Grund eingefallen, warum man zumindest den Gedanken "Wie flexibel bin ich eigentlich?" stets im Hinterkopf behalten sollte:
Der gefürchtete "Management"-Wechsel.
Neue Besen kehren bekanntlich am besten, und ich habe es oft genug erlebt,
dass es jemand neuen im Management gab mit dem berühmten Satz "Alles Mist was ihr da macht. Ab sofort machen wir das so"

Mit meiner Vorgehensweise kann ich sogar den Output eines SQL-Statements ändern, ohne das Frontend neu kompilieren zu müssen, so lange das Interface dasselbe bleibt
(was mir auch tatsächlich schon passiert ist).

Und der "Mehraufwand" im Quell-Code des Frontends, sind vielleicht 3-4 Zeilen Code mehr pro SQL-Aufruf.

Aber wie schon erwähnt: Wenn es so vom Kunden vorgegeben ist, dann ist es so.
Ist ja am Ende nicht meine Baustelle, wenn ich wieder bei Null anfangen muss.

Ganz zu schweigen vom potentiellen "Marketing"-Wert einer Aussage wie
"Wechsel auf ein anderes DB-System? Kein Problem. Muss ich nur die Zugriffs-Lib schreiben, und die SQL-Statements für das andere DB-System schreiben. Rest bleibt so, wie ihr es gewohnt seid. Ihr habt dann halt nen Benziner unter der Haube statt nem Diesel"