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

[Mike_]

Zitat von Bernhard Geyer:

Zitat von Mike_:

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 von Mike_:

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.

[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 von Mike_:

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 von Sir Rufo:

[...] 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 von mkinzler:

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

[dataspider]

Zitat von rwachtel:

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