Ja dann sollte man die ...Klappe halten Gerd. Nicht jeder findet es so toll wen sein Projekt in das er viel Arbeit und Zeit gesteckt hat auf einmal in einen kommerziellen Umfeld auftaucht in dem der Hersteller behauptet das er die Software selbst entwickelt hat, Geld damit scheffelt und nichts an das Projekt zurückgibt.
die Endkunden werden sehr wohl MySQL Support-Verträge abschließen, weil sie 24x7 lauffähig sein wollen. Nicht daß es helfen würde, aber Geld verdienen wird MySQL AB damit schon...
Ich zitiere: "Im Bereich Backup/Recovery wurden die Schwächen von MySQL schon aufgezeigt. Wenn aber die MySQL-Datenbank im Crash-Fall aus einem Legacy-System schnell wieder neu aufgebaut werden kann, sind diese Features gar nicht gefragt. Ein Beispiel dafür: Auf einer Oracle-Datenbank läuft eine transaktionsorientierte Anwendung wie Kontobuchungen, deren Daten einmal pro Nacht in eine MySQL-Datenbank geladen werden, um daraus Reports zu generieren. Sollte MySQL nun abstürzen, wird die Datenbank einfach wieder aus dem Quellsystem neu aufgebaut - die umfangreichen Backup/Recovery-Funktionen wie sie Oracle bietet, sind nicht erforderlich."
Firmen könnten die Programme schreiben, die eng mit der MySQL Datenbank verzahnt wären.
Wer hindert die Unternehmen daran bei MySQL herzugehen und es nicht unter der GPL-Version zu verwenden sondern unter der kommerziellen Lizenz zu lizensieren?
Die jährlichen Lizenzgebühren. Was ist, wenn ich eine Client-Anwendung nicht unter die GPL stelle und dann Lizenzen dieser Anwendung verkaufe? Dann muss der Käufer jedes Jahr Lizenzgebühren an MySQL AB abführen. Wenn man sich anschaut, dass manche Programme für unter 100 Euro über den Ladentisch gehen, bezweifle ich, dass der Kunde in so einem Fall auch noch Lust drauf hätte, jedes Jahr 500 Euro für die Nutzung der in der Anwendung verwendeten Datenbank zu zahlen.
Microsoft verlangt für die Single-User-Version von SQL Server, die z.B. von der Encarta genutzt wird, keinen Cent.
Von Patrick Willam am Sa, 29. Oktober 2005 um 01:23 #
> Tolle wäre eine DBMS, die so einfach zu bedienen wäre wie MySQL und dabei so mächtig wie PostgreSQL.
Ich weiß wirklich nicht, was an PostgreSQL sonderlich schwerer sein soll als an MySQL. Das einzige Fettnäpfchen, das ich kenne -- und in das ich am Anfang auch reingetreten bin -- ist: Der RDBMS-Admin-Account ist nicht 'root' (MySQL) sondern 'postgres' (oder je nachdem 'postmaster'). Also erstmal su - postgres und dann hat man den ganzen Komfort zu Füßen (d.h. im Pfad); als da wären diverse Skripte zum Anlegen und Pflegen von DBs, RDBMS-Accounts, Backups, Replikation etc.pp.
Wenn man den Elefanten erstmal kennengelernt hat, dann schließt man ihn schnell ins Herz aufgrund seiner Stärke, Verläßlichkeit und vielen Talente in Verbindung mit der freundlich-sanften, hilfsbereiten und gutmütigen Art. (Stand so ähnlich auch mal im Linux-Magazin.)
Weil man -- auch wenn man es kann -- nicht immer alles über die Kommandozeile machen will, nimmt man gerne den pgAdmin III zur Hand. Was einem sonst vielleicht noch zum Postgres-Nirvana fehlt, das findet man auf GBorg.
In allen [Performance-]Vergleichen, die ich bisher gesehen oder selber gemacht habe, war PostgreSQL [mit Transaktionen] immer mindestens doppelt so schnell wie MySQL [ohne Transaktionen] und brauchte darüberhinaus höchstens halb soviel RAM. Aber warten wir doch einfach mal die Ergebnisse des c't DBMS-Bencharking-Projektes ab. Da wird sich dann mit etwas Glück auch zeigen, wie die neuen Versionen (MySQL 5.0, PgSQL 8.0/8.1) abschneiden.
Im Übrigen: Meinen Glückwunsch zur 5.0! Scheint ja ein wirklicher Meilenstein zu sein. Beste Grüße, Patrick
PS: Bitte immer schön unterscheiden zwischen einem DBMS (xySQL etc.) und einer Applikation/Oberfläche (Access etc.), die auf ersterer arbeitet. [Fußnote: Die Notlösungs DB-Engines, die Access/OOo/... bereits mitbringen, fallen ja nicht ernsthaft in die Kategorie DBMS.]
Ich kann nur hoffen, daß SCO Code/Applikatioinen draußen bleiben. Ich verstehe auch nicht, wie diese Leute mit SCO eine Partnerschaft eingehen konnten!
es ging da ganz klar, um nur eines, um Geld für MySQL. Ich stimme der Firma zu, daß sie SCO Unix Kunden ein MySQL anbietet, warum auch nicht?
Wie tun "uns" auch keinen Gefallen, wenn wir jetzt immer noch SCO ernst nehmen. Es ist ja ohnehim absehbar, daß Novell und IBM sich die Gelder von SCO mit deren Anwälten teilen werden, da wird von SCO in absehbarer Zeit nichts übrig bleiben können.
Natürlich wäre diese Wunsch-DB in der BSD Lizenz verfügbar....
Das wäre schön !
BSD is dying
Grüße
Sascha
Naja, was fehlt denn jetzt noch großartig?
Natürlich wäre diese Wunsch-DB in der BSD Lizenz verfügbar....
Wo liegt da der Vorteil gegenüber der GPL? (Bitte kurz fassen ;-))
Ciao,
Christian
wir verwenden vermutlich MySQL 5 trotz GPL im unserem kommerziellen Produkt. Ganz einfach, indem wir ODBC und nicht die MySQL Libraries verwenden.
Damit verpassen wir nichts, außer der Chance, nicht portablen Code zu schreiben...
Ach ja, speziellere Sachen werden wir eh nur in Python machen.
Gruß, Kay
die Endkunden werden sehr wohl MySQL Support-Verträge abschließen, weil sie 24x7 lauffähig sein wollen. Nicht daß es helfen würde, aber Geld verdienen wird MySQL AB damit schon...
Gruß, Kay
Vergleiche mal die Backup und Recovery Funktionen von MySQL 5.0 und PosgreSQL 8.1
Transaktionen mit Savepoints geht mit MySQL 5.0 immer noch nicht.
Wo liegt da der Vorteil gegenüber der GPL? (Bitte kurz fassen)
Firmen könnten die Programme schreiben, die eng mit der MySQL Datenbank verzahnt wären.
"Im Bereich Backup/Recovery wurden die Schwächen von MySQL schon aufgezeigt. Wenn aber die MySQL-Datenbank im Crash-Fall aus einem Legacy-System schnell wieder neu aufgebaut werden kann, sind diese Features gar nicht gefragt. Ein Beispiel dafür: Auf einer Oracle-Datenbank läuft eine transaktionsorientierte Anwendung wie Kontobuchungen, deren Daten einmal pro Nacht in eine MySQL-Datenbank geladen werden, um daraus Reports zu generieren. Sollte MySQL nun abstürzen, wird die Datenbank einfach wieder aus dem Quellsystem neu aufgebaut - die umfangreichen Backup/Recovery-Funktionen wie sie Oracle bietet, sind nicht erforderlich."
Quelle:
http://www2.computerwoche.de/index.cfm?pageid=255&artid=81891
MfG
Wer hindert die Unternehmen daran bei MySQL herzugehen und es nicht unter der GPL-Version zu verwenden sondern unter der kommerziellen Lizenz zu lizensieren?
Grüße
Sascha
Microsoft verlangt für die Single-User-Version von SQL Server, die z.B. von der Encarta genutzt wird, keinen Cent.
Ich weiß wirklich nicht, was an PostgreSQL sonderlich schwerer sein soll als an MySQL.
-- ist: Der RDBMS-Admin-Account ist nicht 'root' (MySQL) sondern 'postgres' (oder je nachdem 'postmaster').
Das einzige Fettnäpfchen, das ich kenne -- und in das ich am Anfang auch reingetreten bin
Also erstmal su - postgres und dann hat man den ganzen Komfort zu Füßen (d.h. im Pfad); als da wären diverse Skripte zum Anlegen und Pflegen von DBs, RDBMS-Accounts, Backups, Replikation etc.pp.
Wenn man den Elefanten erstmal kennengelernt hat, dann schließt man ihn schnell ins Herz aufgrund seiner Stärke, Verläßlichkeit und vielen Talente in Verbindung mit der freundlich-sanften, hilfsbereiten und gutmütigen Art. (Stand so ähnlich auch mal im Linux-Magazin.)
Weil man -- auch wenn man es kann -- nicht immer alles über die Kommandozeile machen will, nimmt man gerne den pgAdmin III zur Hand. Was einem sonst vielleicht noch zum Postgres-Nirvana fehlt, das findet man auf GBorg.
In allen [Performance-]Vergleichen, die ich bisher gesehen oder selber gemacht habe, war PostgreSQL [mit Transaktionen] immer mindestens doppelt so schnell wie MySQL [ohne Transaktionen] und brauchte darüberhinaus höchstens halb soviel RAM.
Aber warten wir doch einfach mal die Ergebnisse des c't DBMS-Bencharking-Projektes ab. Da wird sich dann mit etwas Glück auch zeigen, wie die neuen Versionen (MySQL 5.0, PgSQL 8.0/8.1) abschneiden.
Im Übrigen: Meinen Glückwunsch zur 5.0! Scheint ja ein wirklicher Meilenstein zu sein.
Beste Grüße, Patrick
PS: Bitte immer schön unterscheiden zwischen einem DBMS (xySQL etc.) und einer Applikation/Oberfläche (Access etc.), die auf ersterer arbeitet. [Fußnote: Die Notlösungs DB-Engines, die Access/OOo/... bereits mitbringen, fallen ja nicht ernsthaft in die Kategorie DBMS.]
Ich verstehe auch nicht, wie diese Leute mit SCO eine Partnerschaft
eingehen konnten!
es ging da ganz klar, um nur eines, um Geld für MySQL. Ich stimme der Firma zu, daß sie SCO Unix Kunden ein MySQL anbietet, warum auch nicht?
Wie tun "uns" auch keinen Gefallen, wenn wir jetzt immer noch SCO ernst nehmen. Es ist ja ohnehim absehbar, daß Novell und IBM sich die Gelder von SCO mit deren Anwälten teilen werden, da wird von SCO in absehbarer Zeit nichts übrig bleiben können.
Gruß,
Kay