Mein NAS-System bietet 3 Datenbnen zur Auswahl an: MariaDB MySQL PostgreeSQL Ich kenne mich nicht aus mit Datenbanken und möchte mir gerne eine Datenbank einrichten, um mich damit besser auskennen zu lernen. Welche Datenbank ist für den Anfang von den dreien gut geeignet zu Lern- und Übungszwecken?
Anfänger schrieb: > Welche > Datenbank ist für den Anfang von den dreien gut geeignet zu Lern- und > Übungszwecken? MariaDB unabhängig von Oracle und etwas innovativer MySQL Mutter von MariaDB PostgreeSQL schon etwas anspruchsvoller, aber etwas schwerer in der Einarbeitung.
mein letzter wissesnstand ist, das postgres auch exotische datentypen wie geokoordianten (via postgis?) unterstützt. falls du sowas nicht brauchst wird mariadb/mysql geeignet für dich sein, vor allem weil es im net auch viel mehr hilfe dazu gibt.
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...
:
Bearbeitet durch User
Ich würde auch zu PostgreSQL tendieren bei der Auswahl. Habe es auch selber bei meinen Webprojekten im Einsatz.
Wenn es um das Lernen von SQL geht, empfehle ich von diesen Datenbanken PostgreSQL. Denn bei diesem Thema landet man irgendwann beim prozeduralen SQL, meines Wissens nach unterstützt das nur PostgreSQL.
Decius schrieb: > meines Wissens nach unterstützt das nur PostgreSQL. falsch https://dev.mysql.com/doc/connector-net/en/connector-net-tutorials-stored-procedures.html https://mariadb.com/kb/en/mariadb/create-procedure/
@Peter II: Vor einigen Jahren sollte das aber so gewesen sein. Glaube, da gabs die MariaDB noch nicht. Aber kann ja gut sein, dass sich das geändert hat. Deshalb hab ich mich ja so vorsichtig ausgedrückt. ;-) >Ralf Döblitz: >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. 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.
>PostgreSQL kenne ich dagegen als allgemein einsetzbare DB.
Eigentlich nicht richtig. PostgreSQL ist genau genommen ein
Datenbanksystem und keine Datenbank. Erst auf dem Datenbanksystem setzt
man eine anwendungsspezifische Datenbank (z.B. selbsterstellte DB) auf.
:-P
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.
Axel S. schrieb: > 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 geht vermutlich viel mehr um die "Merkwürdigkeiten" bei mysql. Da kann man z.b. Constraints anlegen die aber nur "informativ" also vom System nicht beachtet werden. Klar steht das alles in der Doku - aber von einer DB erwarte ich das es funktioniert oder beim anlegen eine Warnung kommt.
> 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.
Εrnst B. schrieb: > Weil die "echten™"-Datenbanknutzer jetzt nicht mehr mit Verachtung auf > die MariaDB-Frickler herab schauen können? Haters gonna hate. :) Man findet immer wieder ein Opfer auf das man eindreschen und über das man sich erheben kann :)
Εrnst B. schrieb: > Keine Sorge, dann verbünden sich die Postgres- und Mysql-Trolle eben, > und ziehen gemeinsam über MS Access her. MS Access (bzw. die dahinter stehende Jet-Engine) ist überhaupt nicht mit Postgres vergleichbar, mit Mysql hingegen schon eher. Fern vom Standard, eingeschränkte Features und saulahm, wenn's mal wirklich im Sinne einer universellen relationalen DB verwendet werden soll, so weit überhaupt möglich... Für mich kommen bei RDBs nur noch zwei Sachen ernsthaft in Frage: MSSQL und PostgresSQL. Der ganze Rest ist mehr oder weniger Schrott. 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. Lustig: aktuell habe ich mit einer Sache zu tun, die auf einer "Progress"-DB aufsetzt. Na das ist ja erst ein Scheiss. Dagegen ist selbst die MS-Jet-Engine eine wahre Erleuchtung. Der Kram kommt mir vor wie das Zeug, mit dem ich vor drei Jahrzehnten meinen ersten Kontakt mit DBs überhaupt hatte: DBase... Und selbst dieser hochhistorische Dreck dient heute noch als Basis für rezente Software-Produkte. Das glaubt man kaum. Und es gibt offensichtlich immer noch Idioten, die diesen Scheiß kaufen. Mein eigener Brötchengeber z.B.... Das wurde hochkompetent auf GF-Ebene entschieden... Mich hat niemand nach meiner Meinung dazu auch nur befragt...
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?
Peter II schrieb: > und warum nicht MS-SQL? Weils hier um Datenbanken geht um nicht um die beste Möglichkeit, Daten möglichst ineffizient zu speichern?
Elmer schrieb: > Peter II schrieb: >> und warum nicht MS-SQL? > > Weils hier um Datenbanken geht um nicht um die beste Möglichkeit, Daten > möglichst ineffizient zu speichern?
Elmer schrieb: > Peter II schrieb: >> und warum nicht MS-SQL? > > Weils hier um Datenbanken geht um nicht um die beste Möglichkeit, Daten > möglichst ineffizient zu speichern? Ohne weiter Belege dafür, wenig hilfreicher Kommentar.
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.
:
Bearbeitet durch User
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.
Anfänger schrieb: > Mein NAS-System bietet 3 Datenbnen zur Auswahl an: > > MariaDB > MySQL > PostgreeSQL > > Ich kenne mich nicht aus mit Datenbanken und möchte mir gerne eine > Datenbank einrichten, um mich damit besser auskennen zu lernen. Welche > Datenbank ist für den Anfang von den dreien gut geeignet zu Lern- und > Übungszwecken? Nimm einfach PostgreSQL und gut ist IMHO, ist den Alternativen IME ueberlegen in vielerlei Hinsicht. 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. Klar gibt es ein paar Dinge die ein paar RDBMS koennen und andere wiederum nicht, Sequenzen als Beispiel, hat aber weniger mit dem SQL Dialekt zu tun als dmait was das RDBMS eben an Funktionalitaet bietet, aber selbst Sequenzen werden von den genannten ORM zur Not selber implementiert.
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.
Axel S. schrieb: > 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. Witzig dass du anderen Vorurteile unterstellst um dann deinen eigenen zu verbreiten.. Dass Java immer noch die Programmiersprache #1 ist was Verbreitung und Bedarf betrifft ist Fakt, aber das hat anscheinend fuer dich keine Bedeutung. Nebenbei, das heisst "Stacktrace", und war schon immer nur von Entwicklern verwertbar, da hier direkt die Codezeilen referenziert werden.
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.