Von M wie Meikel am Fr, 16. September 2011 um 14:49 #
Vor der Übernahme waren die Kritiker doch stolz auf eine florierende Firma MySQL AB, die mit Support und zusätzlichen Features Geld verdient hat. Dass die MySQL unter einer dualen Lizenz vertrieben und alle externen Entwickler dazu gezwungen haben, ihnen weitreichende Rechte zu überschreiben: nicht so schlimm.
Jetzt gibt es nach wie vor eine Firma, die mit Support und zusätzlichen Features Geld verdient. Das "MySQL Contributor License Agreement" heißt nun "Oracle Contributor Agreement" und Monty Widenius findet das auf einmal ganz schrecklich, seit dem er selber nicht mehr bei der Firma ist.
Und es gibt zusätzlich diverse Forks wie MariaDB oder Drizzle.
Ein Problem sehe ich da auch nicht. Nur wie sieht es für Hersteller mit kommerziellen Programmen aus? können die Ihren Kunden wahlweise MariaDB anbieten (und ist das irgendwo lizensierbar?) oder MÜSSEN kommerzielle Hersteller jetzt auf oracle mysql setzen und damit communtiy abschwören da der Fork sich ja bald bemerkbar machen dürfte.
Von Anonymous am Fr, 16. September 2011 um 15:24 #
Und es gibt zusätzlich diverse Forks wie MariaDB oder Drizzle. Wo genau ist da jetzt weniger Wettbewerb?
Das ist halt die erprobte Oracle- Taktik des "Nobody was ever fired for choosing IBM"-
Wer bisher mit MySQL gut gefahren ist, muss sich jetzt überlegen, auf welches Pferd er künftig setzen soll, ohne dass ihm das in 2 oder 3 Jahren tot umfällt.
Beim Privatmann in seinem Bastelkeller ist das kein grosses Problem; wenn man die Entscheidung für seine Firma treffen soll, wird man geneigt sein, auf den grössten, fettesten und teueresten Gaul zu setzen (früher IBM, heute Oracle).
Ein weiterer Punkt, der mich bisher von PostgreSQL abgehalten hat ist die schlechte/nicht vorhandene Möglichkeit bestehende MySQL Datenbanken nach PostgreSQL zu portieren.
Vielleicht war ich bisher einfach nur zu blind die entsprechenden "freien" Tools für diesen Zweck zu finden. Frei aus diesem Grund, weil ich keine Firma vertrete sondern meinen kleinen unterfinanzierten "Bastelkeller"
Hae? Du kennst dich mit SQL und wie Datenbanken funktionieren aus, oder?
Datenbanken/Tabellen in PostgreSQL anlegen, Daten aus MySQL dumpen und in PostgreSQL wieder reinladen. fertig! Wozu brauchst du jetzt noch Tools? Das größere Problem ist eher, ob deine Applikationen mit PostgreSQL zurechtkommen.
Wie machst du eigentlich Backups von deinen Datenbanken?
Naja, es gibt ja durchaus auch DB spezifische Dinge. Trigger usw. ,die ggf. eben nicht konform mit dem SQL-Subset eines anderen RDBMS sind. Insofern kann es schon sein, dass es bei solchen Konvertierungen zu Problemen kommt. Von Stored Procedures mal gar nicht zu reden...
Die Beweggründe von Oracle sind nun offenkundig. Rechtlich legal, aber der Geist von Open Source ist dabei für MySQL verdunstet.
MySQL kommt auf die Negativ-Liste, denn es werden weitere Deltas entstehen. Es ist anzunehmen, dass die Entwicklung der Community-Version nun nur noch halbherzig betrieben wird.
Nö, Oracle geht einen anderen Weg, erstmal Features in die kommerz. Version, später hat's auch der Rest. Gleiches ist auch bei Solaris, ZFS zu beobachten.
Oracle stellt sich PR mäßig selbst ein Bein. Mal abgesehen ob der Klein-, Mittelanwender in Zukunft noch MySQL benutzt oder nicht, das dürfte auch bei Oracle Nutzern nicht gerade vertrauen auslösen.
Mann kann eigentlich nur jedem raten, weg von Oracle Produkten. Larry Ellison ist ein Großmaul, das hat er schon in vielen Interviews zum Besten gegeben.
Ich sehe keinerlei Unterschied zwischen MySQL AB früher und Oracle jetzt. Die offene Community Edition hatte auch nicht alles, was die kommerzielle hatte. Und nach MySQL AB war alles illegal, was nicht GPL (kompatibel) war und keine Lizenz zahlt. Man hat es dann anderen OpenSource-Projekten sogar erschwert. Ich erinnere nur an den Konflikt mit PHP.
MySQL kann doch eh kaum noch mit PostgreSQL mithalten. Wobei das Feature mit Userauth via LDAP oder Kerberos ganz fein wäre. Aber das habe ich auch in PostgreSQL. Sollen die Doch MySQL kaputt hunzen. Ich setze seit 1 1/2 Jahren nur noch auf PostgreSQL sofern der Kunde nicht nachfragt oder protestiert. Wenn man den Leuten dann in 20 min aufzeigt welche Vorteile sie mit PostgreSQL haben sind viele schon überzeugt. Wenn man ihnen dann vorrechnet welche Kosten sie potenziell bekommen wenn sie doch auf MySQL setzen klappen dann die meisten ein und wedeln das Fähnchen mit dem Elephanten.
Von Unterschied am Sa, 17. September 2011 um 00:54 #
Kannst du mal ein paar Features nennen, die man bei MySQL vermisst und bei Postgres hat? Ist ernst gemeint. Ich nutze beide und muss sagen, dass ich selten hier oder dort etwas vermisse.
Ein gewaltiger Vorteil von MySQL (mit MyISAM), den ich wirklich brauche, ist das extrem schnelle Laden von Daten mit x Millionen Datensätzen. Faktor 10-50. Dadurch kann man Systeme z.B. bzgl. Wiederherstellbarkeit um diesen Faktor nach oben bringen.
also wenn es um "transaktionsfreie" Tabellen geht, kannst Du Dir mal die "unlogged tables" der aktuellen 9.1 ansehen. Pro PostgreSQL: Ich persönlich finde die Window Functions Klasse. Auch gefällt mir in dem Zusammenhang die Möglichkeit, Funktionen und Trigger in SQL oder Perl zu schreiben. Ich stecke gerne soviel Logik wie möglich in die DB. Damit können die verschiedenen Clients so dumm wie möglich sein und Änderungen müssen nur an einer Stelle eingepflegt werden. Ist aber ein Punkt, über den man auch lange Philosophieren kann (Erinnert sich noch Jemand an die Zeit, als MySQL noch keine Fremdschlüssel konnte? Wenn man dieses Feature auf der Mailingliste auch nur Erwähnt hat, wurde man seitenweise zugetextet, dass dies nicht Aufgabe der DB sei, sondern alle Entwickler dies lieber in der Anwendungslogik haben, zwecks besserer Kontrolle ). Bezüglich Tools zur Migration: Da gibt es doch einiges (von Enterprisedb bspw.) und eine Menge Tutorials. Habe jedoch noch keine Migration v. MySQL durchgeführt, kann also nichts über etwaige Probleme sagen.
Mal anders herum gefragt: Gibt es irgendeinen Grund bei einen neuen Projekt *nicht* auf PostgreSQL zu setzten? (Außer wenn man eine file based DB haben will. Da hat man nur die Wahl zwischen SQLite und MySQL.)
Es gibt einige Vorteile von PostgreSQL, für mich gab vor allem aber PostGIS den Ausschlag. Vor allem in Kombination mit GeoDjango eine wirklich schöne Lösung.
Vor der Übernahme waren die Kritiker doch stolz auf eine florierende Firma MySQL AB, die mit Support und zusätzlichen Features Geld verdient hat. Dass die MySQL unter einer dualen Lizenz vertrieben und alle externen Entwickler dazu gezwungen haben, ihnen weitreichende Rechte zu überschreiben: nicht so schlimm.
Jetzt gibt es nach wie vor eine Firma, die mit Support und zusätzlichen Features Geld verdient. Das "MySQL Contributor License Agreement" heißt nun "Oracle Contributor Agreement" und Monty Widenius findet das auf einmal ganz schrecklich, seit dem er selber nicht mehr bei der Firma ist.
Und es gibt zusätzlich diverse Forks wie MariaDB oder Drizzle.
Wo genau ist da jetzt weniger Wettbewerb?
Ein Problem sehe ich da auch nicht.
Nur wie sieht es für Hersteller mit kommerziellen Programmen aus? können die Ihren Kunden wahlweise MariaDB anbieten (und ist das irgendwo lizensierbar?) oder MÜSSEN kommerzielle Hersteller jetzt auf oracle mysql setzen und damit communtiy abschwören da der Fork sich ja bald bemerkbar machen dürfte.
Und es gibt zusätzlich diverse Forks wie MariaDB oder Drizzle. Wo genau ist da jetzt weniger Wettbewerb?
Das ist halt die erprobte Oracle- Taktik des "Nobody was ever fired for choosing IBM"-
Wer bisher mit MySQL gut gefahren ist, muss sich jetzt überlegen, auf welches Pferd er künftig setzen soll, ohne dass ihm das in 2 oder 3 Jahren tot umfällt.
Beim Privatmann in seinem Bastelkeller ist das kein grosses Problem; wenn man die Entscheidung für seine Firma treffen soll, wird man geneigt sein, auf den grössten, fettesten und teueresten Gaul zu setzen (früher IBM, heute Oracle).
"...wenn man die Entscheidung für seine Firma treffen soll, wird man geneigt sein, auf den grössten, fettesten und teueresten Gaul zu setzen..."
...Also PostgreSQL?
Nein Oracle MySQL. PostgreSQL ist zwar bekannt und Bullet-Proof aber bei weitem nicht so groß, fest und teuer wie MySQL.
Ein weiterer Punkt, der mich bisher von PostgreSQL abgehalten hat ist die schlechte/nicht vorhandene Möglichkeit bestehende MySQL Datenbanken nach PostgreSQL zu portieren.
Vielleicht war ich bisher einfach nur zu blind die entsprechenden "freien" Tools für diesen Zweck zu finden. Frei aus diesem Grund, weil ich keine Firma vertrete sondern meinen kleinen unterfinanzierten "Bastelkeller"
Hae? Du kennst dich mit SQL und wie Datenbanken funktionieren aus, oder?
Datenbanken/Tabellen in PostgreSQL anlegen, Daten aus MySQL dumpen und in PostgreSQL wieder reinladen. fertig! Wozu brauchst du jetzt noch Tools? Das größere Problem ist eher, ob deine Applikationen mit PostgreSQL zurechtkommen.
Wie machst du eigentlich Backups von deinen Datenbanken?
Naja, es gibt ja durchaus auch DB spezifische Dinge. Trigger usw. ,die ggf. eben nicht konform mit dem SQL-Subset eines anderen RDBMS sind. Insofern kann es schon sein, dass es bei solchen Konvertierungen zu Problemen kommt. Von Stored Procedures mal gar nicht zu reden...
Die Beweggründe von Oracle sind nun offenkundig.
Rechtlich legal, aber der Geist von Open Source ist dabei für MySQL verdunstet.
MySQL kommt auf die Negativ-Liste, denn es werden weitere Deltas entstehen.
Es ist anzunehmen, dass die Entwicklung der Community-Version nun nur noch halbherzig betrieben wird.
Ergo, Alternativen suchen und unterstützen.
cu
Nö, Oracle geht einen anderen Weg, erstmal Features in die kommerz. Version, später hat's auch der Rest. Gleiches ist auch bei Solaris, ZFS zu beobachten.
Oracle stellt sich PR mäßig selbst ein Bein. Mal abgesehen ob der Klein-, Mittelanwender in Zukunft
noch MySQL benutzt oder nicht, das dürfte auch bei Oracle Nutzern nicht gerade vertrauen auslösen.
Mann kann eigentlich nur jedem raten, weg von Oracle Produkten.
Larry Ellison ist ein Großmaul, das hat er schon in vielen Interviews zum Besten gegeben.
Ich sehe keinerlei Unterschied zwischen MySQL AB früher und Oracle jetzt. Die offene Community Edition hatte auch nicht alles, was die kommerzielle hatte. Und nach MySQL AB war alles illegal, was nicht GPL (kompatibel) war und keine Lizenz zahlt. Man hat es dann anderen OpenSource-Projekten sogar erschwert. Ich erinnere nur an den Konflikt mit PHP.
MySQL kann doch eh kaum noch mit PostgreSQL mithalten. Wobei das Feature mit Userauth via LDAP oder Kerberos ganz fein wäre. Aber das habe ich auch in PostgreSQL. Sollen die Doch MySQL kaputt hunzen. Ich setze seit 1 1/2 Jahren nur noch auf PostgreSQL sofern der Kunde nicht nachfragt oder protestiert. Wenn man den Leuten dann in 20 min aufzeigt welche Vorteile sie mit PostgreSQL haben sind viele schon überzeugt. Wenn man ihnen dann vorrechnet welche Kosten sie potenziell bekommen wenn sie doch auf MySQL setzen klappen dann die meisten ein und wedeln das Fähnchen mit dem Elephanten.
Kannst du mal ein paar Features nennen, die man bei MySQL vermisst und bei Postgres hat? Ist ernst gemeint. Ich nutze beide und muss sagen, dass ich selten hier oder dort etwas vermisse.
Ein gewaltiger Vorteil von MySQL (mit MyISAM), den ich wirklich brauche, ist das extrem schnelle Laden von Daten mit x Millionen Datensätzen. Faktor 10-50. Dadurch kann man Systeme z.B. bzgl. Wiederherstellbarkeit um diesen Faktor nach oben bringen.
also wenn es um "transaktionsfreie" Tabellen geht, kannst Du Dir mal die "unlogged tables" der aktuellen 9.1 ansehen.
).
Pro PostgreSQL: Ich persönlich finde die Window Functions Klasse. Auch gefällt mir in dem Zusammenhang die Möglichkeit, Funktionen und Trigger in SQL oder Perl zu schreiben. Ich stecke gerne soviel Logik wie möglich in die DB. Damit können die verschiedenen Clients so dumm wie möglich sein und Änderungen müssen nur an einer Stelle eingepflegt werden. Ist aber ein Punkt, über den man auch lange Philosophieren kann (Erinnert sich noch Jemand an die Zeit, als MySQL noch keine Fremdschlüssel konnte? Wenn man dieses Feature auf der Mailingliste auch nur Erwähnt hat, wurde man seitenweise zugetextet, dass dies nicht Aufgabe der DB sei, sondern alle Entwickler dies lieber in der Anwendungslogik haben, zwecks besserer Kontrolle
Bezüglich Tools zur Migration: Da gibt es doch einiges (von Enterprisedb bspw.) und eine Menge Tutorials. Habe jedoch noch keine Migration v. MySQL durchgeführt, kann also nichts über etwaige Probleme sagen.
Grüße p
Mal anders herum gefragt: Gibt es irgendeinen Grund bei einen neuen Projekt *nicht* auf PostgreSQL zu setzten? (Außer wenn man eine file based DB haben will. Da hat man nur die Wahl zwischen SQLite und MySQL.)
Es gibt einige Vorteile von PostgreSQL, für mich gab vor allem aber PostGIS den Ausschlag. Vor allem in Kombination mit GeoDjango eine wirklich schöne Lösung.