PostgreSQL steht unter der BSD-Lizenz, welche die Nutzung und Distribution ohne Lizenzgebühren sowohl für kommerzielle als auch für nicht-kommerzielle Anwendungen erlaubt.
MySQL steht unter der GPL-Lizenz, welche die Nutzung und Distribution ohne Lizenzgebühren sowohl für kommerzielle als auch für nicht-kommerzielle Anwendungen erlaubt.
SCNR, hjb, aber könntest du oben "welche die Nutzung" durch "welche wie die GPL die Nutzung" ersetzen? Ist weniger missverständlich, finde ich.
Stimmt ja so hundertprozentig auch nicht. Die BSD-Lizenz erlaubt mir beispielsweise, dass ich das Produkt ändern bzw. anpassen und als kommerzielles Produkt wieder vertreiben kann. GPL hat diese zusätzliche Freiheit eben nicht.
> Die BSD-Lizenz erlaubt mir beispielsweise, dass ich das Produkt ändern bzw. anpassen und als kommerzielles Produkt wieder vertreiben kann. GPL hat diese zusätzliche Freiheit eben nicht.
Natürlich erlaubt die GPL das. Du musst nur den Quellcode mitliefern.
Das ist wohl kaum das was er mit "kommerzielles Produkt" meint. Eben die Pflicht den Quellcode mitzuliefern hat die BSD Lizenz nicht. Daher kann man nicht einfach die BSD Lizenz direkt mit der GPL auf eine Stufe stellen.
Wie die GPL ist aber falsch, denn die BSD Lizenz ermöglicht klassische kommerzielle nicht-freie Anwendungen. Das kommerzielle in der GPL liegt ja auch nur darin, dass man damit irgendwie versuchen darf Geld zu verdienen. Die GPL erlaubt es, aber die BSD Lizenz erlaubt es nicht WIE die GPL
als ich das letzte Mal geguckt habe, waren die Client-Libraries von MySQL noch unter GPL. Anders gesagt, MySQL ist nur für Freie Software kommerziell nutzbar, und sonst nur, wenn man Geld für ne andere Lizenz bezahlt.
Ist halt so.
In die Kernel-Welt übertragen, wäre der Effekt vergleichbar damit, wenn die glibc nicht LGPL sondern GPL wäre. Dann wäre nicht-GPL kompatible Software auf dem Kernel nicht mehr auszuführen.
> aber könntest du oben "welche die Nutzung" durch "welche wie die GPL die Nutzung" ersetzen? Ist weniger missverständlich, finde ich.
Warum sollte man das dort hinschreiben und die GPL extra erwähnen? Sie hat absolut gar nichts mit dem Artikel zu tun. Und was soll irgendwie missverständlich sein? Es wird lediglich gesagt was man durch die BSD bekommt.
Von Michael Lehmeier am Mi, 1. Juli 2009 um 21:50 #
Hab schon mal PostGIS zusammen mit GRASS verwendet. Nicht übermäßig Feature-reich, aber für alles was ich brauchte vollkommen ausreichend. Manchmal ist für die Zusammenarbeit viel Skriptarbeit nötig, aber dann kann man eigentlich alles machen, was man sich so wünscht. Kann ich wirklich empfehlen.
Die PostGIS-Erweiterung ermöglicht Dir die Speicherung von Geometrien in der Datenbank und umfangreiche Abfrage- und Manipulations-Möglichkeiten derselben. Dabei greift PostGIS selbst auf die geos-Bibliothek zurück, die sich selbst als eine C-Portierung der JTS (Java Topology Suite) beschreibt. Wir arbeiten schon einige Jahre mit PostgreSQL und PostGIS und kennen schon viele Stärken und einige Schwächen des Gespanns.
Eine Frage ist natürlich, welche Geodaten-bezogene Software Du an die Datenbank anschließen möchtest.
Blöde Frage von einem, der nie ESQL verwendet hat: ist die ESQL-Implementierung nicht in erster Linie ein Frage der Sprache, in die sie eingebettet wird?
nein, der Sinn von ESQL ist es, dass die SQL-Anfragen zu Übersetzungszeit ausgewertet werden (so weit es geht) und in dem Compilat bereits optimierte Aufrufe an die DB enthalten sind. Darüber hinaus ermöglicht eine ausgereifte ESQL Implementierung die Verwendung von komplexen Hostvariablen (structure), somit man z.B. ganze Zeilen auf einmal einlesen kann. (das z.B. wegen software engineering)
Ich versteh jetzt aber nicht genau, wo denn da der Unterschied zu normalem SQL liegt. Für jedes SQL wird ein Ausführungsplan erstellt ("compiliert"). Dabei ist es egal, ob das vor 5 Tagen ein SQL Precompiler gemacht hat oder zur Laufzeit die Datenbank (außer, dass das aktuell gepartse Statement neuere Statistiken zur Verfügung hat, und ESQL nicht).
Was verstehst Du unter ganze Zeilen einlesen? Ich kann über Arrayprocessing auch mehrere Zeilen auf einmal binden und dann an die DB schicken. Was das mit Software Engineering zu tun hat erschließt sich mir überhaupt nicht.
"Dabei ist es egal, ob das vor 5 Tagen ein SQL Precompiler gemacht hat oder zur Laufzeit die Datenbank"
Soweit ich es verstanden habe bekommst du für ein ungültiges SQL Statement bei ESQL schon zur Kompilierungszeit eine Fehlermeldung, bei üblichen Variante scheitert es schlimmstenfalls erst beim Kunden.
Wobei man das natürlich mit sowieso nötigen Testsuites auch abfangen kann.
Wobei man das natürlich mit sowieso nötigen Testsuites auch abfangen kann.
Ja allerdings. Wenn das Programm ungetestet zum Kunden geht, dann hilft auch das fehlerfrei kompilierte ESQL nichts wenn leider die Ergebnisse falsch sind Was aber weitaus schlimmer ist: Eine SQL Änderung zieht zwingendermaßen auch eine Programmänderung mit sich. Habe ich die Statements z.B. in eine Datei oder besser noch in die DB selbst ausgelagert kann ich ggf. Korrekturen vornehmen ohne das Programm nochmal neu übersetzen zu müssen.
in den Mailinglisten gibt es zu genüge Nachfragen hauptsächlich an Herrn Meskes, zuletzt hat er in Februar erwähnt, er wollte mal die Implementierung neu über SPI machen und nicht über libpg. Aber auch das ist (zwar in der Denkweise der 'postrgesql-ianer' richtig) aber hat mit ESQL nicht zu tun. Bei Postrgesql ist aber esql generell nicht berücksichtigt worden (meine ich) und deswegen geht es wohl nicht, dass die sql-statements vorab (vor dem c-compiler) ausgewertet werden und in dem c-programm dann bereits Funktionsaufrufe drin sind, die dem Ausführungsplan folgen.
Wir haben Test durchgeführt und es liegen Welten zwischen Datenbanken, die richtig ESQL unterstützen (informix, adabas) und pgsql.
Warum gibts eigentlich noch keine Datenbank-Flamewars, wo sich doch sonst über jeden Scheiss gestritten wird? Vielleicht brauch man dazu zuviel Ahnung von DBs? Aber es geht doch sonst auch ohne fundierte Argumente.
Ich fang einfach mal an: PostgreSQL könnte evtl. ein Patent von Oracle verletzen, deshalb ist es böse und gehört nicht in die Standardinstallation von Slackware! MySQL ist nur ein billiger Abklatsch, PGSQL war schließlich zuerst da! MySQL ist besser weils viel häufiger verwendet wird, und Millionen Fliegen ...! SQL ist generell nur Marketing-Blabla, dBase ist die einzig wahre DB! SQLite ist das Maß aller Dinge, schließlich ist TCP/IP gefährlich! Alles Quatsch, Access vom Weltmarktführer ist der Standart!
Lotus Notes ist [b]die[/b] Datenbank, vor allem für Dokumente. Also, die Datenbank, die bei mir Brechreiz auslöst. Um um "Datenbank" gehören "" drumherum.
MySQL steht unter der GPL-Lizenz, welche die Nutzung und Distribution ohne Lizenzgebühren sowohl für kommerzielle als auch für nicht-kommerzielle Anwendungen erlaubt.
SCNR, hjb, aber könntest du oben "welche die Nutzung" durch "welche wie die GPL die Nutzung" ersetzen? Ist weniger missverständlich, finde ich.
hu'ASC'ar
Stimmt ja so hundertprozentig auch nicht. Die BSD-Lizenz erlaubt mir beispielsweise, dass ich das Produkt ändern bzw. anpassen und als kommerzielles Produkt wieder vertreiben kann. GPL hat diese zusätzliche Freiheit eben nicht.
Natürlich erlaubt die GPL das. Du musst nur den Quellcode mitliefern.
als ich das letzte Mal geguckt habe, waren die Client-Libraries von MySQL noch unter GPL. Anders gesagt, MySQL ist nur für Freie Software kommerziell nutzbar, und sonst nur, wenn man Geld für ne andere Lizenz bezahlt.
Ist halt so.
In die Kernel-Welt übertragen, wäre der Effekt vergleichbar damit, wenn die glibc nicht LGPL sondern GPL wäre. Dann wäre nicht-GPL kompatible Software auf dem Kernel nicht mehr auszuführen.
Gruss,
Kay
Warum sollte man das dort hinschreiben und die GPL extra erwähnen? Sie hat absolut gar nichts mit dem Artikel zu tun. Und was soll irgendwie missverständlich sein? Es wird lediglich gesagt was man durch die BSD bekommt.
gruss snoooobi
http://de.wikipedia.org/wiki/PostGIS
Sonnigen Gruß vom Postboten
Nicht übermäßig Feature-reich, aber für alles was ich brauchte vollkommen ausreichend. Manchmal ist für die Zusammenarbeit viel Skriptarbeit nötig, aber dann kann man eigentlich alles machen, was man sich so wünscht.
Kann ich wirklich empfehlen.
Eine Frage ist natürlich, welche Geodaten-bezogene Software Du an die Datenbank anschließen möchtest.
Darüber hinaus ermöglicht eine ausgereifte ESQL Implementierung die Verwendung von komplexen Hostvariablen (structure), somit man z.B. ganze Zeilen auf einmal einlesen kann. (das z.B. wegen software engineering)
Was verstehst Du unter ganze Zeilen einlesen? Ich kann über Arrayprocessing auch mehrere Zeilen auf einmal binden und dann an die DB schicken. Was das mit Software Engineering zu tun hat erschließt sich mir überhaupt nicht.
Dim
Soweit ich es verstanden habe bekommst du für ein ungültiges SQL Statement bei ESQL schon zur Kompilierungszeit eine Fehlermeldung, bei üblichen Variante scheitert es schlimmstenfalls erst beim Kunden.
Wobei man das natürlich mit sowieso nötigen Testsuites auch abfangen kann.
Ja allerdings. Wenn das Programm ungetestet zum Kunden geht, dann hilft auch das fehlerfrei kompilierte ESQL nichts wenn leider die Ergebnisse falsch sind
Was aber weitaus schlimmer ist: Eine SQL Änderung zieht zwingendermaßen auch eine Programmänderung mit sich. Habe ich die Statements z.B. in eine Datei oder besser noch in die DB selbst ausgelagert kann ich ggf. Korrekturen vornehmen ohne das Programm nochmal neu übersetzen zu müssen.
Bei Postrgesql ist aber esql generell nicht berücksichtigt worden (meine ich) und deswegen geht es wohl nicht, dass die sql-statements vorab (vor dem c-compiler) ausgewertet werden und in dem c-programm dann bereits Funktionsaufrufe drin sind, die dem Ausführungsplan folgen.
Wir haben Test durchgeführt und es liegen Welten zwischen Datenbanken, die richtig ESQL unterstützen (informix, adabas) und pgsql.
Ich fang einfach mal an:
PostgreSQL könnte evtl. ein Patent von Oracle verletzen, deshalb ist es böse und gehört nicht in die Standardinstallation von Slackware!
MySQL ist nur ein billiger Abklatsch, PGSQL war schließlich zuerst da!
MySQL ist besser weils viel häufiger verwendet wird, und Millionen Fliegen ...!
SQL ist generell nur Marketing-Blabla, dBase ist die einzig wahre DB!
SQLite ist das Maß aller Dinge, schließlich ist TCP/IP gefährlich!
Alles Quatsch, Access vom Weltmarktführer ist der Standart!
So, irgendein Klischee vergessen zu bedienen?
ich schätze mal es liegt daran, dass viele Leute nichts mit Postgre anfangen können. Bei KDE vs Gnome sieht das schon anders aus...
Ist mir letztens aber auch bei der Wireshark Meldung aufgefallen. Da waren erstaunlich wenige Kommentare.
Ich persönlich halte mich hier zurück, da ich über Postgre keine Aussagen treffen kann. Aber informativ finde ich die News dennoch
So long...
P.S.: Ja, ich mußte so was mal bauen.