Mysql, postgreeSql oder mariaDb?

Anfänger schrieb:
> Welche
> Datenbank ist für den Anfang von den dreien gut geeignet zu Lern- und
> Übungszwecken?

Nimm die Postgres, die ist wenigstens standardkonform. Wenn du z.B. 
irgendwelche Beispiele aus Lehrbüchern nacharbeiten willst, dann wirst 
du bei Postgres wohl kaum um irgendwelche Fehler/Merkwürdigkeiten/Warts 
herumbasteln müssen.

Von MySQL kann ich nur nur abraten, das ist ein grauenhafter Haufen 
Müll, bei dem vielleicht die ersten zwei, drei Schritte einfach 
erscheinen, aber danach wird es dann zunehmend unangenehmer (store 
procedures, Trigger, ...).

Ralf D. schrieb:
> Von MySQL kann ich nur nur abraten, das ist ein grauenhafter Haufen
> Müll, bei dem vielleicht die ersten zwei, drei Schritte einfach
> erscheinen, aber danach wird es dann zunehmend unangenehmer (store
> procedures, Trigger, ...).

Wobei man aber sagen muss, dass viele Anwendungen völlig ohne sowas 
auskommen können. Kommt halt auf die Anwendung an, nicht immer brauchts 
eine Full-featured DB.

Ich kenne Firmen, die nehmen ein Oracle10 für eine Handvoll Tabellen mit 
max 20000 Zeilen und machen im wesentlichen nur 'select * where id=x'. 
Ist schon Perlen vor die Säue...

Decius schrieb:
>
> Würde aber trotzdem PostgreSQL wählen(siehe erster Abschnitt Ralf
> Döblitz). Denn MySQL war dafür gedacht in Verbindung mit DB-gestützten
> Webseiten eingesetzt zu werden, und war deshalb auf diesen Zweck
> optimiert. PostgreSQL kenne ich dagegen als allgemein einsetzbare DB.

Das ist Blödsinn. MySQL und PGSQL sind relationale Datenbanksysteme. Sie 
sind beide für jede Art von Anwendungen nutzbar und brauchen im 
Zweifelsfall jeweils spezifische Optimierungseinstellungen.

Es gibt im PostgreSQL-Lager eine weit verbreitete Ablehnung von (um 
nicht zu sagen einen Haß auf) MySQL und Verwandte. Der ist aber 
weitgehend irrational (Neid?) und für einen Anfänger ist es am Ende 
vollkommen Wurst, welche dieser Datenbanken er verwendet. An Grenzen 
wird er so schnell bei keinem System stoßen.

Für MySQL (und MariaDB, das bei der Nutzung zu 99% das gleiche ist) 
spricht dabei die weitere Verbreitung, was zu einer größeren Community 
und folglich zu mehr Hilfe im Netz führt.

> es geht vermutlich viel mehr um die "Merkwürdigkeiten" bei mysql.

Naja, das grosse Oracle ist bei den Merkwürdigkeiten nicht besser...

Peter II schrieb:

> es geht ... mehr um die "Merkwürdigkeiten" bei mysql.
>
> Da kann man z.b. Constraints anlegen die aber nur "informativ" also vom
> System nicht beachtet werden.

Du meinst sicher CHECK() Constraints, die der MySQL SQL-Parser zwar 
akzeptiert, aber ansonsten ignoriert. Ja, das war sicher keine 
Sternstunde, als Monty diese Entscheidung getroffen hat. Er suchte halt 
eine pragmatische Lösung, um fremdes DDL in MySQL reinladen zu können.

Allerdings gibt es schlechte Neuigkeiten (für PGSQL-Verfechter - für 
alle anderen sind es gute Neuigkeiten). MariaDB 10.2 (derzeit Beta) 
implementiert CHECK() [1]. Mal sehen wie lange Oracle dafür noch braucht 
in MySQL ;)


[1] https://mariadb.com/kb/en/mariadb/what-is-mariadb-102/

Abradolf L. schrieb:
> Warum sind das schlechte Neuigkeiten?

Weil die "echten™"-Datenbanknutzer jetzt nicht mehr mit Verachtung auf 
die MariaDB-Frickler herab schauen können?

Keine Sorge, dann verbünden sich die Postgres- und Mysql-Trolle eben, 
und ziehen gemeinsam über MS Access her.

Peter II schrieb:
> c-hater schrieb:
>> Für mich kommen bei RDBs nur noch zwei Sachen ernsthaft in Frage: MSSQL
>> und PostgresSQL. Der ganze Rest ist mehr oder weniger Schrott.
>
> und warum nicht MS-SQL?

Mit der Microsoftschen Variante habe ich zwar nie gespielt, dafür aber 
mit der guten alten Sybase OSE. Die beiden haben einen gemeinsamen 
Vorfahren, Unterschiede waren damals nur in recht kleinen Details (und 
natürlich dem OS, auf dem das RDBMS lief).

Sybase hat zwar auch ein paar Häßlichkeiten gehabt, die aber alle 
irgendwie erträglich oder umgehbar waren. Das ist schon ein ordentliches 
Teil, das auch IIRC sehr weit standkonform war. Vom Handling her empfand 
ich die Sybase als angenehmer als die Oracle, durch die sie bei uns 
abgelöst wurde.

c-hater schrieb:
> Für mich kommen bei RDBs nur noch zwei Sachen ernsthaft in Frage: MSSQL
> und PostgresSQL. Der ganze Rest ist mehr oder weniger Schrott.

Es kommt schon ein wenig drauf an, was man damit machen will. Als 
Backend-Store eines anspruchslosen Webservers ist MS-SQL eine meist 
etwas zu dicke Kanone. Es ist auch nicht jede DB-Anwendung arg 
Performance- und Feature-sensitiv, so dass MySQLs auch mit zig GB Inhalt 
ihre Daseinsberechtigung haben.

> Früher(tm) gehörten auch noch Oracle und DB2 dazu. Aber die sind
> praktisch abgehängt. Die existieren eigentlich nur noch durch die
> schiere Masse der existierenden Installationen.

Oracle hat sich mittlerweile quasi selbst abgehängt und eine 
Fluchtbewegung ausgelöst. Die Lizenzierung ist dermassen irre, dass es 
nur jemand verwendet, der absolut keine Wahl hat.

Ich habe früher für einige von mir entwickelte Systeme Mysql verwendet, 
auch ein paar Projekte übernommen die Mysql verwendet haben. Wie das 
halt so ist - am Anfang "nur ne kleine Webanwendung". Über die Jahre 
kommen dann aber hier und da immer mehr Features dazu.

Mich hat das Mysql dann bei fast jedem dieser Systeme immer wieder 
irgendwo gebissen - irgendetwas substantielles fehlte. Z.B. die 
Constraints, die fehlende Volltextsuche im InnoDB-Backend (das MyISAM 
hatte es, dafür fehlte aber Row-locking und vieles andere wichtige), 
richtiger Unicode-Support, keine Materialized Views,...

Auch bei anderen Punkten war die Implementation oft so, daß es auf den 
ersten Blick so aussah als ob es ginge, dann im Detail aber irgendwelche 
schwerwiegenden Einschränkungen auftauchten. Z.B. konnte man ein Charset 
"utf8" einstellen. Da denkt man natürlich daß das ein ganz normales, 
vollständiges UTF-8 ist. Aber Pustekuchen, das erlaubt nur manche 
Zeichen und andere gehen nicht. Später wurde dann "utf8mb4" eingeführt, 
erst das erlaubte dann volles Unicode.

Mittlerweile hat das Mariadb viele fehlende Punkte nachgerüstet. Aber 
ich glaube die Materialized Views sind z.B. auch heute nur über nen 
externes Plugin möglich. Auch wieviele versteckte Fallen ähnlich wie 
mein utf8-Beispiel noch irgendwo im Code lauern weiß ich nicht.

Selbst mit DB-Abstraktionslayern kannst Du nicht mal eben auf ne andere 
DB umsteigen, da die SQL-Syntax halt doch anders ist.

Ich nehme daher für neue Projekte von Anfang an nur noch Postgresql. Da 
muss ich mir keine Sorgen machen wenn die Anforderungen wachsen. Und 
komplizierter finde ich es auch nicht.

Gerd E. schrieb:
> am Anfang "nur ne kleine Webanwendung". Über die Jahre
> kommen dann aber hier und da immer mehr Features dazu.

Ich hab das öfter andersrum. ;-)

Die Anwendung bleibt über Jahre unverändert, weil Praktikant/Azubi/DHler 
über alle Berge oder man hat sich vom Entwicklerbüro unfreundlich 
getrennt - aber das System drunter kann mit diesem Phlegma nicht 
mithalten und wechselt gezwungenermassen die MySQL und PHP Versionen.

Gerd E. schrieb:
> Ich habe früher für einige von mir entwickelte Systeme Mysql verwendet,
> auch ein paar Projekte übernommen die Mysql verwendet haben.
...
> Mich hat das Mysql dann bei fast jedem dieser Systeme immer wieder
> irgendwo gebissen - irgendetwas substantielles fehlte. Z.B. die
> Constraints, die fehlende Volltextsuche im InnoDB-Backend (das MyISAM
> hatte es, dafür fehlte aber Row-locking und vieles andere wichtige),
> richtiger Unicode-Support, keine Materialized Views,...
...
> Ich nehme daher für neue Projekte von Anfang an nur noch Postgresql.

Ein geradezu prototypisches "MySQL ist Mist, nur PG ist eine richtige 
Datenbank" Posting. Auch Vorurteile haben ein Haltbarkeitsdatum. Schau 
dir einfach mal ein aktuelles MySQL oder MariaDB an. Da bleibt kaum noch 
was von deinen Vorurteilen übrig.

Ansonsten soll natürlich jeder verwenden, was ihm gefällt. Aber wenn 
schon Kritik geübt wird, dann bitte korrekt.

> ich glaube die Materialized Views sind z.B. auch heute nur über nen
> externes Plugin möglich

Das ist das IMNSHO meistüberschätzteste Feature eines RDBMS überhaupt. 
Caches dieser Art gehören in die Anwendung (u.a. weil sie der 
Anwendungslogik unterliegen) und nicht in die Datenbank.

> Selbst mit DB-Abstraktionslayern kannst Du nicht mal eben auf ne andere
> DB umsteigen, da die SQL-Syntax halt doch anders ist.

So ist das wohl. Und wenn man doch versucht, eine generische Abstraktion 
zu verwenden, verschenkt man dir größere Hälfte der Vorteile, die das 
Backend eigentlich bieten würde.

Skippy schrieb:
> Gerd E. schrieb:
>> Selbst mit DB-Abstraktionslayern kannst Du nicht mal eben auf ne andere
>> DB umsteigen, da die SQL-Syntax halt doch anders ist.
>
> Ist es nicht Aufgabe der Abstraktionslayer das SQL an sich zu
> abstrahieren? ;)
> Hibernate, EclipseLink, DataNuclues schaffen das alle, so als Beispiele
> aus der Java Welt, da wird das SQL passend zum RDBMS generiert.

Autsch. Diese Persistenzlayer sind das #1 Problem für Entwickler, DBA 
und Hersteller-Support. Das erzeugte SQL ist für Menschen praktisch 
unlesbar und in vielen Fällen auch nicht performant ausführbar. Grob 
vergleichbar mit Politik oder der Wurstproduktion. Wer die Details 
einmal kennen gelernt hat, will nie wieder etwas damit zu tun haben ...

Daß du das mit Java in einem Atemzug nennst, bestätigt auch wieder alle 
Vorurteile, die man nur haben kann. Abstraktionslayer ohne Ende 
aufeinandergestapelt als ob es kein morgen gäbe. Performance oder 
Wartbarkeit (fangen wir einfach mal mit der Lesbarkeit eines Backtrace 
an) haben für diese "Programmierer" anscheinend keine Bedeutung.

Axel S. schrieb:
> Ein geradezu prototypisches "MySQL ist Mist, nur PG ist eine richtige
> Datenbank" Posting. Auch Vorurteile haben ein Haltbarkeitsdatum. Schau
> dir einfach mal ein aktuelles MySQL oder MariaDB an. Da bleibt kaum noch
> was von deinen Vorurteilen übrig.

Das sind keine Vorurteile, sondern eigene Erfahrungen die ich mit 
älteren Mysql-Versionen gemacht habe. Es mag mit neuen Versionen besser 
sein - das hab ich ja auch geschrieben.

Aber derartige Probleme sind mir in den Jahren seit ich Postgresql nutze 
bisher nicht begegnet. Solange mir MariaDB keine deutlichen Vorteile 
bietet werde ich bei Postgresql bleiben.

Mein Wissen um Datenbanken ist nicht mehr so frisch, aber das ist auch 
eigentlich nicht so wichtig, da jede große Datenbank SQL versteht. 
Sicher, einige haben ihr "eigenes" SQL, dennoch wirst du später (besser 
früher) sowieso alles mit SQL machen.
SQL ist recht einfach, wenn man Englisch kann.
Man merkt sich das gut, weil du eigentlich nur schreiben musst, was du 
willst. Also so: create table.
Als ich quasi aufhörte mit den Datenbanken, da wurde MySQL gerade 
populär. Ich würde das heute nehmen, weil die auch hinter vielen 
Webseiten steckt. Alternativ Postgres, aber nur, weil ich MariaDB nicht 
kenne.

Bei MySQL vs MariaDB läuft es in Linux u.U. drauf raus, welche Distro 
man verwendet, so man fertige Pakete präferiert. Die eine hat MySQL 
drin, die andere MariaDB.

Skippy schrieb:
> Dass Java immer noch die Programmiersprache #1 ist was Verbreitung und
> Bedarf betrifft ist Fakt, aber das hat anscheinend fuer dich keine
> Bedeutung.

Ändert aber nichts daran, dass das bevorzugte Entwicklungsmodell in Java 
aus Abstraktionen-auf-Abstraktionen-auf-Abstraktionen besteht. Und dass 
das, wenn man es strikt nach Buch ad nauseam durchzieht, große Scheiße 
ist, wird durch Javas Verbreitung auch nicht besser.

Spätestens da, wo die Realität (in diesem Fall: die Datenbank, bzw. SQL) 
anfängt, muss man die Abstraktion brechen. Und Java zieht an der Stelle 
gerne noch eine zusätzliche Abstraktionsbruch-Abstraktionsebene ein, was 
irgendwo ziemlich lächerlich ist.

F. F. schrieb:
> Alternativ Postgres, aber nur, weil ich MariaDB nicht kenne.

MariaDB vs. MySQL ist grob vergleichbar mit LibreOffice vs. OpenOffice.

Beide sind äquivalent und entwickeln sich getrennt voneinander weiter. 
Kennst du das eine, kennst du auch das andere, und im Prinzip ist es 
auch egal, welches von beiden du verwendest (solange es keine der 
neueren Funktionen betrifft).

Skippy schrieb:
> Axel S. schrieb:

>> Daß du das mit Java in einem Atemzug nennst, bestätigt auch wieder alle
>> Vorurteile, die man nur haben kann. Abstraktionslayer ohne Ende
>> aufeinandergestapelt als ob es kein morgen gäbe. Performance oder
>> Wartbarkeit (fangen wir einfach mal mit der Lesbarkeit eines Backtrace
>> an) haben für diese "Programmierer" anscheinend keine Bedeutung.
>
> Dass Java immer noch die Programmiersprache #1 ist was Verbreitung und
> Bedarf betrifft ist Fakt, aber das hat anscheinend fuer dich keine
> Bedeutung.

In der Tat nicht. Die Vergangenheit hat oft genug gezeigt, daß 
Marktdominanz und Produktqualität bestenfalls lose gekoppelt sind. Siehe 
VHS, IBM-PC oder Windows.

Was Programmiersprachen angeht, da habe ich genug gesehen und verwendet, 
um schöne (elegante, ausdrucksstarke) solche von den anderen 
unterscheiden zu können. Und Java kommt da sehr weit unten raus. C# ist 
in etwa das, was Java hätte sein sollen. Leider kommt es vom falschen 
Vendor. Andererseits setze ich eine gewisse Hoffnung in Oracle. Die 
haben bis jetzt noch jedes Open Source Projekt kaputt gekriegt. Wäre 
doch gelacht, wenn sie das bei Java nicht auch schaffen. Bei Openoffice 
ging es ja sehr schnell. Und Solaris und MySQL wackeln auch schon.