> Der Grund hierfür ist der überwiegende Einsatz des Systems aus Schweden in den bekanntesten Applikationen.
Ich würde eher da auf die breite Unterstützung seitens der Webspaceanbietern tipppen anstatt den Programmen die Ursache zu suchen. Die Programmautoren nehmen einfach das am meisten unterstützte seitens der Webanbieter.
> Ich würde eher da auf die breite Unterstützung seitens der Webspaceanbietern tipppen anstatt den Programmen die Ursache > zu suchen. > Die Programmautoren nehmen einfach das am meisten unterstützte seitens der Webanbieter.
das ist ja nur einen schritt weiter gedacht:
der "anwender" (welcher tools wie bugzilla, ein wiki, ... mit hilfe der DB einsetzen will) muss sich entscheiden: welche db nehme ich? -> mysql weil damit die meißten tools aus problemlos funktioniern.
der entwickler der tools muss sich entscheiden: für welche DB entwickle ich? -> mysql weil das die meißten provider/anwender verwenden.
ich sehe hier eher die klassische spirale. selbst wenn sie es wollten könnten anwender und entwickler nicht umsteigen. der anwender müsste aus einige tools verzichten. der entwickler auf einen großen teil seiner "kundschaft". also entweder es steigen beide (anwender und entwicker) um, oder man macht die datenbanken kompatibel. die entwickler könnten natürlich die anwendungen selbst zu beiden DBs kompatibel machen, was aber natürlich einen (je nach qualität des codes, kleinen oder großen) mehraufwand bringen würde.
Das ist ungefähr das gleiche wie bei Firefox und MS: Da hat Firefox auch Erweiterungen eingebaut, um eine nicht Standard-konforme Implementierung zu emulieren.
Für Migration vielleicht ganz nett, aber keine Dauerlösung. Immerhin fängt mysql jetzt auch mal an, Standards zu befolgen.
> Da hat Firefox auch Erweiterungen eingebaut, um eine nicht > Standard-konforme Implementierung zu emulieren.
Richtig, zu den eigenen nicht Standard-konformen Erweiterungen, über die nicht gesprochen wird, kamen tatsächlich mit der Zeit fremde nicht Standard-konforme Erweiterungen dazu. So läuft das halt, trotzdem ist mir nicht ganz klar, was der Vergleich aussagen soll - das genannte Beispiel ist doch ein Beispiel für eine Situation, in der beide Seiten dasselbe Vorgehen nutzen, zum Belegen eines einseitigen Werturteils also völlig ungeeignet.
diesen Schritt kann ich nur begrüßen und hoffe, dass die Qulität des Layers ausreichend ist. Da der Bekanntheitsgrad von MySQL dem von PostgreSQL übersteigt - was sicherlich nicht mit technischem Vorsprung zu begründen ist, sondern eher durch Einsatz von Massenhostern und Marketinggetöse von MySQL AB - hoffe ich, dass PostgreSQL mit dieser Arbeit den Nutzerkreis erweitern kann.
Das Problem bei den DatenbankAbstraktionen (z.B. bei Perl oder PHP) ist, daß sie nur den kleinsten gemeinsamen Nenner (+ ein paar emulierte Funktionen) unterstützen. Will man Umfangreicheren Zugriff auf die Datenbank, muß man sich immer spezialisieren.
es scheint mir das es langsam wirklich unübersichtlich wird. es gibt schon genug offene datenbank abstraktion layer die eigentlich des programierers erste wahl sein solten. jdbc odbc. php selber hat mehere database abstraktionslayer wie adodb, dbx, PEAR:DB, oder die PHPLib.
jedes anständige projekt solte auf so einer schnittstelle aufbauen. dan braucht man genau in der config datei eine zeile anzupassen.
es sei mir erlaubt : alles andere isch "müeslifresser"-style.
diese schnittstelle kommt somit meiner meinung nach von der falschen seite. anstatt datenbank unabhängige applikationen zu schreiben , macht dieser autor seine datenbank unabhängig. auch ein ansatzt *smile*
Das eine hat hier mit dem anderem nix zu tun. Es geht hier darum, das SQL-Verhalten zu emulieren bzw. SQL-Funktionen von mysql. Da kann ich mit jdbc, odbc, usw. drauf zugreifen oder mit was auch immer, dort gebe ich dann SQL ein und wenn Datenbank-System x den Befehl nicht versteht ist Schicht. Darum geht es, soweit ich das sehen kann.
Klar könnte man. Nur braucht man für Hibernate schon einiges mehr an Resourcen. Mit den 8MB, die einem manche Massenwebhoster als memory_limit für PHP-Skripte anbieten, kommt man da garantiert nicht aus. *g* Und man kann wohl kaum für primitive Webanwendungen wie phpBB nen root-/Managed-Server verlangen. Das wäre ja mit Kanonen auf Spatzen geschossen.
Und selbst Hibernate nutzt nicht alle Features des jeweiligen DBMS. Da kann man zwar native SQL verwenden, verliert aber die DBMS-Unabhängigkeit.
Das kann man doch schon lang, sogar in verschiedenen Sprachen, und das dient der Datensicherheit, wenn man von verschiedenen Applikationen auf die DB zugreift, wenn die Logik teilweise in dieser liegt.
Warum dient es der Datensicherheit, in einem SELECT ein IF haben zu dürfen und damit, wenn man will, auch einen Benchmark oder was auch immer ausführen zu können?
Ich würde eher da auf die breite Unterstützung seitens der Webspaceanbietern tipppen anstatt den Programmen die Ursache zu suchen.
Die Programmautoren nehmen einfach das am meisten unterstützte seitens der Webanbieter.
> zu suchen.
> Die Programmautoren nehmen einfach das am meisten unterstützte seitens der Webanbieter.
das ist ja nur einen schritt weiter gedacht:
der "anwender" (welcher tools wie bugzilla, ein wiki, ... mit hilfe der DB einsetzen will) muss sich entscheiden:
welche db nehme ich? -> mysql weil damit die meißten tools aus problemlos funktioniern.
der entwickler der tools muss sich entscheiden:
für welche DB entwickle ich? -> mysql weil das die meißten provider/anwender verwenden.
ich sehe hier eher die klassische spirale. selbst wenn sie es wollten könnten anwender und entwickler nicht umsteigen. der anwender müsste aus einige tools verzichten. der entwickler auf einen großen teil seiner "kundschaft". also entweder es steigen beide (anwender und entwicker) um, oder man macht die datenbanken kompatibel.
die entwickler könnten natürlich die anwendungen selbst zu beiden DBs kompatibel machen, was aber natürlich einen (je nach qualität des codes, kleinen oder großen) mehraufwand bringen würde.
Da hat Firefox auch Erweiterungen eingebaut, um eine nicht Standard-konforme Implementierung zu emulieren.
Für Migration vielleicht ganz nett, aber keine Dauerlösung.
Immerhin fängt mysql jetzt auch mal an, Standards zu befolgen.
> Standard-konforme Implementierung zu emulieren.
Richtig, zu den eigenen nicht Standard-konformen Erweiterungen, über die nicht gesprochen wird, kamen tatsächlich mit der Zeit fremde nicht Standard-konforme Erweiterungen dazu. So läuft das halt, trotzdem ist mir nicht ganz klar, was der Vergleich aussagen soll - das genannte Beispiel ist doch ein Beispiel für eine Situation, in der beide Seiten dasselbe Vorgehen nutzen, zum Belegen eines einseitigen Werturteils also völlig ungeeignet.
diesen Schritt kann ich nur begrüßen und hoffe, dass die Qulität des Layers ausreichend ist. Da der Bekanntheitsgrad von MySQL dem von PostgreSQL übersteigt - was sicherlich nicht mit technischem Vorsprung zu begründen ist, sondern eher durch Einsatz von Massenhostern und Marketinggetöse von MySQL AB - hoffe ich, dass PostgreSQL mit dieser Arbeit den Nutzerkreis erweitern kann.
Gruß,
Censor
>schlicht nicht möglich, mehrere Datenbanken zu unterstützen.
Wozu gibt's denn database abstraction layer?!
Für php z.B. adodb.
jedes anständige projekt solte auf so einer schnittstelle aufbauen. dan braucht man genau in der config datei eine zeile anzupassen.
es sei mir erlaubt : alles andere isch "müeslifresser"-style.
diese schnittstelle kommt somit meiner meinung nach von der falschen seite. anstatt datenbank unabhängige applikationen zu schreiben , macht dieser autor seine datenbank unabhängig. auch ein ansatzt *smile*
Da kann ich mit jdbc, odbc, usw. drauf zugreifen oder mit was auch immer, dort gebe ich dann SQL ein und wenn Datenbank-System x den Befehl nicht versteht ist Schicht.
Darum geht es, soweit ich das sehen kann.
Mit den 8MB, die einem manche Massenwebhoster als memory_limit für PHP-Skripte anbieten, kommt man da garantiert nicht aus. *g*
Und man kann wohl kaum für primitive Webanwendungen wie phpBB nen root-/Managed-Server verlangen. Das wäre ja mit Kanonen auf Spatzen geschossen.
Und selbst Hibernate nutzt nicht alle Features des jeweiligen DBMS. Da kann man zwar native SQL verwenden, verliert aber die DBMS-Unabhängigkeit.
Jede Datenbank ist besser als der kleinste gemeinsame Nenner.
Außer für Kleinkram ist die grundsätzlich zu begrüßende Datenbankunabhängigkeit einfach Quatsch. Dazu sind die ernstzunehmenden Vertreter zu komplex.
NikN
NikN
Etwas Bildung hilft beim Verständnis von SQL und relationalen Datenbankmodellen.
Es geht um Trigger und Stored Prozedures.
Programmieren konnte man schon lange, was sicher einem nicht sauberen Stil widerspricht... oder verstehe ich irgendwas völlig falsch?