Firebird vs MySQL Embedded [Price, Performance [...]]

[Mike_]

Guten Abend,

ich bin gerade über einen interessanten Artikel gestoßen:
http://www.delphifeeds.com/go/f/73941
sowie dadurch dann auf:
http://blog.marcocantu.com/blog/mysq..._firebird.html

Zusammenfassend steht darin, dass MySQL nur "gratis" ist, sofern es unter den GPL Bedingungen genutzt/gestellt wird, was bei Unternehmen so gut wie nie der Fall ist, da der SourceCode öffentlich zugänglich sein müsste (Für die Applicationen welche den MySQL Server nutzen).

Zitat:

MySQL is free only for GPL projects (plus some other FLOSS licences, if you want to be precise). This means you have to release the source code of your application if you don't want to pay for the DB.

Nun, ich bin gerade dabei eine Applikation zu entwickeln und stehe vor der DB "Auswahlgeschichte".

Firebird ?
MySQL?
Auf jeden Fall embedded.


Es handelt sich um ~ 1000 Datensätze.

Meine Googlercherche und Suchtreffer hier im Board ergaben viele informative Ergebnisse, wobei aber z.T. widersprüchliches herauskam.

Bestes Beispiel:
Überwiegend habe ich gelesen dass MySQL performanter läuft, eine bessere Dokumentation bietet und allg. "stabiler" läuft.

Firebird macht das Gegenteil und soll Caseinsensitive sein.
(Quelle: http://forums.mysql.com/read.php?84,...352#msg-251352)

Dann sagt jemand es sei alles anders und Firebird ist viel besser als MySQL.
(Quelle: http://forums.mysql.com/read.php?84,...969#msg-235969)

Nun frage ich mich natürlich, warum sollte man dann Firebird der MySQL DB vorziehen ?
Ist es der von mir angesprochene Preis, den man eigentlich bezahlen müsste wenn man MySQL Anwendungen vertreibt in einer Firma ?

Muss man überhaupt für MySQL zahlen oder ist die Quelle vllt. auch "widersprüchlich" ?


Es wäre klasse wenn man in diesem Thread die Sachen klar stellen könnte :)

[Chemiker]

Hallo Mike_,

also zu MySQL kann ich nichts sagen, aber ich habe eine 24/7 Installation von Firebird zur Messwerte-Erfassung. Dort werden am Tag über 100.000 Datensätze gespeichert, bisher läuft der Server ohne Schwierigkeiten. Bei 1.000 Datensätze glaube ich nicht, dass es einen großen Unterschied macht welchen Server eingesetzt wird. Firebird ist kostenlos.

Bis bald Chemiker

[Bernhard Geyer]

Zitat:

Zitat von Mike_ (Beitrag 1079648)

Zusammenfassend steht darin, dass MySQL nur "gratis" ist, sofern es unter den GPL Bedingungen genutzt/gestellt wird, was bei Unternehmen so gut wie nie der Fall ist, da der SourceCode öffentlich zugänglich sein müsste (Für die Applicationen welche den MySQL Server nutzen).

Gilt nicht wenn man
- DB-Server nur intern verwendet
- Bei SW-Verkauf auch ohne MySQL-DLLs/Units auskommt und der Kunde selbst darum kümmert einen MySQL-Server zu bekommen.

Zitat:

Zitat von Mike_ (Beitrag 1079648)

Auf jeden Fall embedded.

Ok. Damit ist der Kostenfaktor bei Verwendung von Nicht-Transaktions-DB-Engine ca. 20k-30k€ pro Jahr. Bei InnoDB mehr.

Zitat:

Zitat von Mike_ (Beitrag 1079648)

Es handelt sich um ~ 1000 Datensätze.

Bei 1000 Datensätze könnte man auch XML zur Speicherung nehmen und alles In-Memory halten.

[ThomasBab]

Hallo!

Ich kann Chemiker zu zustimmen. Bei mir läuft auch ein (embedded) Firebird, der pro Tag ca 500000 Meßwerte erfaßt.

Der letzte Neustart des Erfassungsprogramms liegt ca 6 Monate zurück. Grund für den Neustart war ein Update des Programms.

Meine Delphi-Intranet Anwendung, die auch auf eine Firebird (embedded) Datenbank zugreift läuft auch seit 6 Monaten problemlos. Diese Datenbank ist knapp 2GB groß. Geschwindigkeitsunterschiede zu dem Zeitpunkt, als sie nur 500 MB groß war, kann ich nicht feststellen.

Achso, noch etwas: als Zugriffskomponenten benutze ich die uib-Komponenten von: http://www.progdigy.com/?page_id=5

Gruß
Thomas

[mkinzler]

Zitat:

Zitat von http://forums.mysql.com/read.php?84,231000,251352#msg-251352

Firebird can do Case Insensitive search only if you use UTF-8 character set.

FireBird erlaubt case insensitive collations

Zitat:

Firebird has a tiny set of builtin functions which I find to be poorly documented.

Die Anzahl steigt mit jeder Version.
Es werden aber weitere in Form von UDF-Biblioteken mitgeliefert, zudem lässt die FreeAdhocudf-Lib kaum Wünsche offen.

[Mike_]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1079653)

Zitat:

Zitat von Mike_ (Beitrag 1079648)

Zusammenfassend steht darin, dass MySQL nur "gratis" ist, sofern es unter den GPL Bedingungen genutzt/gestellt wird, was bei Unternehmen so gut wie nie der Fall ist, da der SourceCode öffentlich zugänglich sein müsste (Für die Applicationen welche den MySQL Server nutzen).

Gilt nicht wenn man
- DB-Server nur intern verwendet
- Bei SW-Verkauf auch ohne MySQL-DLLs/Units auskommt und der Kunde selbst darum kümmert einen MySQL-Server zu bekommen.

Müssen beide Punkte erfüllt sein oder ist es möglich, dass der Server nur intern verwendet wird und dadurch die .dll´s legal mitgegeben werden können ?

Was versteht man unter "SW-Verkauf auch ohne MySQL-DLLs/Units auskommt", beutet dies dass das Programm auch ohne diese .dll´s seine Aufgabe erledigen können muss oder einfach nur dass die Firma sich die Dateien selbst herunterlädt und es so "abnimmt" ?


Also allgemein gesprochen entnehme ich diesem Thread, dass es keinen wirklich ausgeprägten Grund gibt, auf Firebird als MySQL Alternative zu verzichten. (Selbst bei größeren Datenmengen)


Danke für eure persönlichen Erfahrungen. :)

[mkinzler]

Zitat:

Zitat von Mike_ (Beitrag 1079728)

Müssen beide Punkte erfüllt sein oder ist es möglich, dass der Server nur intern verwendet wird und dadurch die .dll´s legal mitgegeben werden können ?

Die Dlls dürfen dann nicht weitergegeben werden.

Zitat:

Was versteht man unter "SW-Verkauf auch ohne MySQL-DLLs/Units auskommt", beutet dies dass das Programm auch ohne diese .dll´s seine Aufgabe erledigen können muss oder einfach nur dass die Firma sich die Dateien selbst herunterlädt und es so "abnimmt" ?

Besser ist das erstere ( z.B. durch Verwendung von DevArt-Kompos)

Zitat:

Also allgemein gesprochen entnehme ich diesem Thread, dass es keinen wirklich ausgeprägten Grund gibt, auf Firebird als MySQL Alternative zu verzichten. (Selbst bei größeren Datenmengen)

Ein Bisschen komisch formuliert.
Die Aussagen von MySQL-Anwendern in einem MySQL-Forum über ein anderes DBMS, muss man natürlich werten. Eine Aussage, dass FireBird weniger perfomant ist, genausowenig richtig, wie umgekehrt.
Die größe der Datenmenge sollte für sich nichts an der Performance eines DBMS ändern.

[Bernhard Geyer]

Zitat:

Zitat von Mike_ (Beitrag 1079728)

Müssen beide Punkte erfüllt sein oder ist es möglich, dass der Server nur intern verwendet wird und dadurch die .dll´s legal mitgegeben werden können ?

Wenn die Anwendung nur für Firmeninterne Einsätze gedacht ist dann hat man keine Probleme.

Zitat:

Zitat von Mike_ (Beitrag 1079728)

Was versteht man unter "SW-Verkauf auch ohne MySQL-DLLs/Units auskommt", beutet dies dass das Programm auch ohne diese .dll´s seine Aufgabe erledigen können muss oder einfach nur dass die Firma sich die Dateien selbst herunterlädt und es so "abnimmt" ?

Auch wenn die Firma die DLL's selbst herunterlad ist dein Programm Lizenzpflichtig bzw. dein Kunde benötigt eine Serverlizenz. Aber mit Devart (und anderen Komponentenherstellern) welche die Netzwerkkommunikation mit dem Server selbst durchführen ohne Fremd-DLL's ist man aus dem Schneider.

Zitat:

Zitat von Mike_ (Beitrag 1079728)

Also allgemein gesprochen entnehme ich diesem Thread, dass es keinen wirklich ausgeprägten Grund gibt, auf Firebird als MySQL Alternative zu verzichten. (Selbst bei größeren Datenmengen)

Am besten du implementierst den Support für mehrere DBMS und überlast den Kunden auszusuchen welche er nehmen will. Meist ist eh schon ein Oracle, MySQL oder MS SQL-Server im Einsatz und er kann die DB auf einem bestehenden Server aufsetzen. Schreibst du ihn ein DBMS vor, so wirst du für jeden Sch... mit dem Server von der Firma verantwortlich gemacht (bzw. versucht). "Sie haben ja bei uns einen Firebird/MySQL-Sever installiert/nötig gemacht ..."

[Mike_]

Das ist ein wertvoller Tipp Herr Geyer, vielen Dank dafür.

Leider ist es mir z.Zt. nicht möglich solch eine kostenpflichtige Komponente zu verwenden.

Ich selbst arbeite z.Zt. mit ZEOS, welche nach meinem Wissensstand nur die Verbindung per .dll ermöglicht. [MySQL]

Daher werde ich für embedded Systeme und OpenSource Projekte nun auf Firebird setzen, u.a. aufgrund des überaus positiven Bildes welches mir hier vermittelt wurde.

MySQL kommt mir nur dann ins Haus, sofern das Programm explizit für eine Firma ist welche auf MySQL setzt.

[QUOTE=mkinzler;1079730]

Zitat:

Zitat von Mike_ (Beitrag 1079728)

Eine Aussage, dass FireBird weniger perfomant ist, genausowenig richtig, wie umgekehrt.
Die größe der Datenmenge sollte für sich nichts an der Performance eines DBMS ändern.

Der letzte Satz erschließt sich mir nicht richtig.

Ich habe bereits öfters von Kollegen gehört, dass z.T. der MySQL Server aufgrund der Datenmenge die dieser beinhaltet von der Performanceleistung deutlich langsamer geworden ist (z.B. bei Suchanfragen o.Ä.).

Dies erscheint mir auch logisch und dass gerade bei größeren Datenmengen Performanceunterschiede feststellbar sind bei FireBird im Vergleich zu MySQL (o.Ä.) ist m.M.n. ein rationaler Gedanke gewesen.

Sollte dies nicht zutreffen, lerne ich aber gerne dazu :)

[Sir Rufo]

Ein jedes DBMS wird langsamer wenn die Datenmengen so gross werden, dass diese nicht so richtig in den zur Verfügung stehenden Arbeitsspeicher passen. Dann wird es nicht langsam sondern schnarchlahm.

Was ein jedes DBMS langsam macht sind fehlende Schlüssel auf den Suchspalten.

Bei MySQL hatte die InnoDB Engine tatsächlich einen Performanceeinbruch, der mit der neuesten MySQL Version aber behoben sein soll.

BTW vielleicht ist ja SQLite noch eine Alternative?

[Bernhard Geyer]

MySQL ist i.d.R. nicht viel langsamer/schneller als andere DB-Systeme. Bremsende Faktoren sind primär schlecht Programmierte Software oder fehlerhafte Konfiguration des Servers. Hier kann man bei MySQL oder Oracle viel falsch machen.

[mkinzler]

Aus Sicht des Users im MySQL-Forum, ist es ja nicht MySQL sondern FireBird, was so unperformant sei.

[rwachtel]

Zitat:

Zitat von Sir Rufo (Beitrag 1079801)

[...] BTW vielleicht ist ja SQLite noch eine Alternative?

Ich kann auch nicht verstehen, wieso bei "Embedded" und "<100.00 Datensätze" überhaupt noch über etwas anderes als SQLite auch nur ansatzweise nachgedacht werden sollte... ;)

[mkinzler]

Vielleicht wenn
-das Programm nicht nur embedded ist
-man sich schon in einem anderem DBMS auskennt
-man SQLite nicht mag
...

[rwachtel]

Zitat:

Zitat von mkinzler (Beitrag 1079805)

Vielleicht wenn
-das Programm nicht nur embedded ist [...]

War nicht im Geringsten die Rede von.

Zitat:

-man sich schon in einem anderem DBMS auskennt

...dauert es wenige Minuten, bis man sich auch in SQLite zurechtfindet.

Zitat:

-man SQLite nicht mag

Das fragilste Deiner an sich schon äußerst schwachen Argumente. Persönliche Befindlichkeiten waren schon immer ein äußerst schlechter Ratgeber - aber es soll ja auch Leute geben, die einen Nagel mit einem Schraubendreher in die Wand schlagen, weil sie keinen Hammer mögen - ob diese als Handwerker nachhaltigen Erfolg haben würden, lasse ich ich jetzt mal so dahingestellt... ;)

[mkinzler]

Zitat:

Das fragilste Deiner an sich schon äußerst schwachen Argumente...

Geistig schwache Zeitgenossen mit fragilem Pseudo-Halbwissen wie ich, denken und entscheiden nun mal so. :stupid:

Wer sich z.B. mit Firebird/MySQL/MSSQL auskennt, wird in diesem Fall (1 Benutzer rein lokal/embedded) auch Firebird embedded/MySQL embedded/MSSQL compact einsetzen, wenn vielleicht auch eine andere bessere Lösung für das Problem existiert ( XML, SQLite) zudem sich die Zielrichtung des Programmes ja ändern könnte ( MU, zentrale Datenhaltung, ...)
Fachleute wie du würden natürlich zur Besten Premiumlöung greifen.

Zitat:

...dauert es wenige Minuten, bis man sich auch in SQLite zurechtfindet.

Welchem einem erspart bleiben, wenn man eine bekannte Lösung wählt.

[dataspider]

Zitat:

Zitat von rwachtel (Beitrag 1079804)

Ich kann auch nicht verstehen, wieso bei "Embedded" und "<100.00 Datensätze" überhaupt noch über etwas anderes als SQLite auch nur ansatzweise nachgedacht werden sollte... ;)
...
Persönliche Befindlichkeiten waren schon immer ein äußerst schlechter Ratgeber ...

Was denn nun?

Frank

[Mike_]

mkinzler,

genau so hatte ich auch gedacht, aufgrund der Tatsache dass ich mit MySQL bisher alles erledigt hatte.

Aufgrund der Tatsache, dass Programme dadurch aber Lizenzpflichtig werden (könnten), habe ich mich auf die Suche nach alternativen gemacht.

Nun bin ich außerdem noch auf folgendes gestoßen:
http://www.delphi-treff.de/tutorials...en-mit-mybase/

Auch eine interessante Alternative.

Aufgrund der in meinen Augen höheren Popularität der Firebird DB werde und dem Lizenzhickhack von MySQL werde ich nun des FireBird´s bedienen einlesen.

[rwachtel]

Zitat:

Zitat von dataspider (Beitrag 1079827)

Was denn nun?

Der Bedeutung von Emoticons bist Du Dir aber schon im Klaren, oder?

Und Dein krampfhafter Versuch, einen Bezug zu meiner ersten Aussage herzustellen ist ziemlich gründlich daneben gegangen...

[alzaimar]

Nun kriegt euch mal wieder ein, wasndas für eine Rumzickerei hier?
Es ist sehr wohl legitim, aus persönlichen Grunden ein RDBMS abzulehnen.

Beschränkt euch auf die fachliche Auseinandersetzung zu dem Thema und lasst das Kleinkarierte bitte außen vor.

Dankeschön.

Ich habe mir nicht jeden Post durchgelesen, aber ich glaube, man sollte vielleicht erst einmal ergründen, was der Threadsteller denn mit der DB anstellen möchte.
Sind es wirklich nur die 1000 Datensätze?? Bisher ist dem nicht wiedersprochen worden.
Soll immer nur ein Anwender auf die Daten zugreifen?
Was soll mit den Daten gesehen? Umfangreiche Suche usw?

Bei 1000 Datzensätzen muss es noch nicht mal ein RDMBS sein, auch wenn es noch so Lite ist. Eine Textdatei reicht hier u.U. auch.

Also Leute, aufs Thema konzentrieren, bitte.

[Mike_]

Es geht um einen "Werkzeugkasten", d.h. per XML/in der Datenbank werden 2-3 Treeviews gespeichert sowie eine Verknüpfung der Endknoten jedes Trees mit entsprechendem Inhalt welcher im Editor rechts daneben dargestellt wird.

(Ähnlich der Funktionsweise des "Microsoft Dokument Explorer", auch als "Delphi Hilfe" bekannt.)

Es wird immer nur ein Anwender sein welcher darauf zugreift.
Die Datensätze können auch auf 2000 steigen oder auch bei 500 liegen, je nachdem was man in seinen Werkzeugkasten alles füllt.

Die Applikation wird Open-Source.


Lokale Dateiformate (Kann man dies so nennen ?) wie .txt, .xml etc. möchte ich nicht für die Einträge verwenden, nur für den/die TreeView/s.

Soweit wurden meine Fragen jedoch schon hervorragend beantwortet.

[rwachtel]

Zitat:

Zitat von alzaimar (Beitrag 1079939)

[...] Es ist sehr wohl legitim, aus persönlichen Grunden ein RDBMS abzulehnen. [...]

Nie etwas anderes behauptet.

Genau genommen ist es sogar legitim aus welchen Gründen auch immer ein RDBMS abzulehnen - ich stellte lediglich die Sinnhaftigkeit und die Nachhaltigkeit der Wahl eines falschen Werkzeugs in Frage.

Und bei der Anforderung des OPs würde ich ein "großes" RDBMS wie FireBird oder MySQL - egal wie Embedded sie letztendlich sein mögen - als genauso sinnig wie die Verwendung eines Sitzrasenmähers für die Zerkleinerung von Schnittlauch fürs Abendbrot ansehen.

Dann tatsächlich lieber eine Textdatei (aber bitte mit strukturiertem Aufbau à la XML).

[rwachtel]

Zitat:

Zitat von Mike_ (Beitrag 1079943)

Es geht um einen "Werkzeugkasten", d.h. per XML/in der Datenbank werden 2-3 Treeviews gespeichert sowie eine Verknüpfung der Endknoten jedes Trees mit entsprechendem Inhalt welcher im Editor rechts daneben dargestellt wird. [...]

Also geht es um darzustellende (evtl. größere) Dokumente? Dann würde ich u.U. sogar eine dokumentenorientierte Datenbank wie z.B. CouchDB oder MongoDB in den Raum werfen.

[Mike_]

Zitat:

Zitat von rwachtel (Beitrag 1079947)

Zitat:

Zitat von alzaimar (Beitrag 1079939)

[...] Es ist sehr wohl legitim, aus persönlichen Grunden ein RDBMS abzulehnen. [...]

Und bei der Anforderung des OPs würde ich ein "großes" RDBMS wie FireBird oder MySQL - egal wie Embedded sie letztendlich sein mögen - als genauso sinnig wie die Verwendung eines Sitzrasenmähers für die Zerkleinerung von Schnittlauch fürs Abendbrot ansehen.

:lol:

[QuickAndDirty]

Cool, also würde ihm der FB - Classic Server ausreichen...

Seit es den FB Super Server gibt arbeiten wir an einer Portierung nach Firebird...wir haben es getestet und es ist ganz brauchbar. MSSQL ist zwar schneller aber wir unterstützen beides und FB hat dabei noch den Vorteil umsonnst zu sein und das es quasi ohne Installation als Super Server laufen kann (classic geht in unserem Fall gar nicht) und Wenn dann mal ein Server notwendig wird ist das auch kein Problem...weil mehrer FB Server neben einander laufen können...ich muss meine Datanbank also nicht wie in MSSQL irgendwie einfügen und auf vorhandene Benutzer und Datenbanken und Firmen Rücksicht nehmen...

Das einzige was glaube ich nervt ist die nicht einstellbare(??oder??) Beschränkung der Länge für Bezeichner von Feldern. Wenn ein Feld mit einem Deutschen zusammengesetzten Wort bezeichnet werden soll wird es schon mal eng.

[mkinzler]

Tja FireBird SuperServer/SuperClassic/ClassicServer ist nun mal nicht embedded. Die embedded basiert aber auf SuperClassic

[tsteinmaurer]

Embedded = SuperClassic => Seit Firebird 2.5. In vorherigen Versionen basiert Embedded auf SuperServer.

Thomas

[QuickAndDirty]

Seit 2.5 können wir es embedded benutzen ...weil wir mindestens 2 Programme brauchen die gleichzeitig zugreifen können. Das war vor 2.5 mit embedded nicht möglich.

Soweit ich mich an die Anleitung erinnere gibt es einen Embedded FB Classic der nur Zugriff von einer Anwendung aus erlaubt und ein Embedded SuperClassic der zwar auch nur die Dlls benötigt aber Zugriff von mehr als einer Anwendung auf dem Lokalen Rechner auf die selbe DB erlaubt. Das letzte läuft zumindest hier in den Tests ganz gut.

[mkinzler]

Bei Calssic ging das früher schon. Die alten embedded verwendeten aber SuperServer, ab 2.5 SuperClassic