Wahl der passenden Datenbank

  • Hallo zusammen,


    ich plane aktuell ein Projekt und bin jetzt beim Punkt Datenbank angekommen. Ich habe mich jetzt schlau gemacht über verschiedene Datenbanksysteme. Bin mir aber nicht so ganz sicher welche Datenbank wirklich am besten geeignet ist. Zur Auswahl stehen im prinzip


    - SQLite
    - MySQL
    - PostgreSQL


    Ich selbst habe bis jetzt nur mit SQLite gearbeitet, da hier nach meiner Meinung der Vorteil ist das der ganze Datenbank Server Kram entfällt. Der Nachteil ist aber auch das bei mehreren Programme die auf die Datenbank zugreifen Verzögerungen auftreten können. Bei SQLite sehe ich auch bei einem vServer den Nachteil das hier kein Cache vorhanden ist was zu mehr Festplattenzugriffen führt, welche aber "limitiert" sind.


    Meine Frage an euch mit Datenbank Erfahrung ist nun ob sich die Geschwindigkeit der gennanten Systeme wirklich so sehr unterscheidet. Ich gehe jetzt von einer kleinen Datenbank mit < 10.000 Datensätzen aus. Über den Aufbau der Datenbank kann ich leider noch nichts sagen da es wie gesagt alles noch frühe Planungsphase ist :) Gibt es hier ein paar Grundsätze die man berücksichtigen kann? Wichtig wäre auch der Punkt der Anpassbarkeit. Bei SQLite sehe ich das Problem das es kompliziert wird wenn ein Projekt wächst. Bei MySQL/PostgreSQL ist man da im Vorteil.


    Bei MySQL und PostgreSQL kommt leider im Gegensatz zu SQLite noch der Ressourcenverbrauch des Datenbankservers hinzu, der natürlich auch noch extra verwaltet werden will...


    Als Sprache kommt Python zum Einsatz.


    Ich danke für eure Antworten


    Grüße

  • Sowohl MySQL als auch PostgreSQL sind natürlich extrem mächtig. MySQL lässt sich aber relativ leicht auf 32MB drücken, wenn man sich mal mit der Konfiguration beschäftigt. PostgreSQL ist angeblich resourcenschonender als MySQL.


    Ich weiß jetzt nicht wieviel Programmiererfahrung du hast noch was der Einsatzzweck deines Programmes ist, aber der generelle Datenbankzugriff in der Programmierung unterscheidet sich oft nur eine winzige Kleinigkeit: Type of Database. Der Zugriff erfolgt in der Regel über Schnittstellen/Klassen und der SQL-Syntax bleibt gleich, sprich du kannst den Datenbanktyp einfach wechseln. Das ist ja gerade der Witz an SQL.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Also könnte ich im Prinzip erst einmal SQLite einsetzen und wenn ich merke das es meinen Anforderungen nicht genügt durch den Wechsel des Datenbantreibers einfach eine andere Datenbank nutzen. Die notwendigen Änderungen sollten da ja recht klein sein...


    Grüße

  • Zitat von slukas;35738

    eine möglichkeit wäre auch noch or-mapping einzusetzen.
    (vgl. http://de.wikipedia.org/wiki/Objektrelationale_Abbildung)


    dadurch ersparst du dir das schreiben von sql-qrys im code selbst und bist noch eine spur flexibler was das darunter liegende dbms anbelangt.


    Bevor die Wahl auf einen OR-Mapper fallen kann, muss man aber erst mal die Programmiersprache kennen. Gibt es ORM auch bei PHP?


    Weiterhin gibt es wie überall Theorie und Praxis: sprich die Mapper können zwar laut Datenblatt mit vielen DBs betrieben werden, aber eine Migration von einem RDBS auf ein anderes funktioniert nur selten ohne Zusatzaufwand. Ja, die Queries müssen nicht unbedingt angepasst werden.
    Aber die Datenmigration selbst bedeutet Aufwand und das zugehörige OR-Mapping muss u. U. auch passend geändert werden.


    vmk:
    Die festen SQL-Versionen sind nur der kleineste gemeinsame Nenner den alle DBs unterstützen. Sobald die Schemas komplexer werden oder man Performance-Optimierungen einbaut ist man oft auf Statements angewiesen, welche nicht mehr portabel sind.


    Die Wahl der Datenbank sollte also schon mit Weitblick betrieben werden.


    Leider kann ohne Projekt-Details keine allgemeine Empfehlung gegeben werden.


    Schönen Gruß,
    Lars

  • Ich danke euch für eure Ratschläge. Ich habe mich in der Zwischenzeit auch noch mal schlau gemacht.


    SQLite ist also für einfache Aufgaben mehr als geeignet, da sich aber alles in einer Datei abspielt muss die gesamte Datenbank bei Zugriffen gesperrt werden. Wenn also mehrere Nutzer zur gleichen Zeit auf die Datenbank zugreifen wird es mit steigendenden Zugriffszahlen immer langsamer. Bei einzelnen Zugriffen ist aber SQLite in vielen Fällen schneller als MySQL.


    Ich habe mich jetzt aber für MySQL entscheiden müssen, da es einfach nicht akzeptabel ist wenn eine Datenbank bei jedem Zugriff komplett gesperrt ist. Ich denke mit MySQL werde ich nicht viel falsch machen können.


    Jetzt werde ich mich nur noch schlau machen müssen wie man eine solche Datenbank sicher einrichtet :)


    Grüße

  • Zitat von christian;35765

    SQLite ist also für einfache Aufgaben mehr als geeignet, da sich aber alles in einer Datei abspielt muss die gesamte Datenbank bei Zugriffen gesperrt werden. Wenn also mehrere Nutzer zur gleichen Zeit auf die Datenbank zugreifen wird es mit steigendenden Zugriffszahlen immer langsamer.


    das ist schon lange nicht mehr so, seit Version 3 kann eine SQLite-Datenbank auch von mehreren Prozessen gleichzeitig genutzt werden.
    Einzig Schreiben kann nur ein Prozess gleichzeitig [1], aber das wäre auch genauso mit MyISAM unter MySQL.
    Solange du keine riesigen Concurrency-Anforderungen hast sollte SQLite deine Anforderungen locker erfüllen können ;)


    Zitat von christian;35765

    Bei einzelnen Zugriffen ist aber SQLite in vielen Fällen schneller als MySQL.


    unterschreibe ich so nicht.
    Das ist eine pauschale Aussage, die per Definition somit schon falsch ist, es wird sicherlich Anwendungsbereiche geben bei denen es so ist, aber auch genug bei denen andersherum ist.


    Zitat von christian;35765

    Ich denke mit MySQL werde ich nicht viel falsch machen können.


    Solange du InnoDB mit Transaktionen verwendest dann nicht ;)



    [1] http://www.sqlite.org/faq.html#q5

  • Ich weiß gar nicht, wieso man SQLite verwenden möchte, wenn man nicht sehr ressourcenbeschränkt ist. Die Speicherstruktur sollte es gar nicht erlauben, eine so gute Anfrageoptimierung zu erreichen, wie bei MySQL oder PostgreSQL. Die ISAM-Speicherung ist auch nicht die effizienteste - referenzielle Integrität ist glaub ich gar nicht möglich. Ist ja nicht viel anders, als das Aneinanderhängen von Blöcken.


    Ein OR-Mapper ist sehr komfortabel, aber nicht zu empfehlen, wenn das Ganze super performant sein soll.


    Es ist auch immer die Frage, was man denn mit dem DBMS machen möchte. Überleg dir die Zugriffe und Statements. Kann man das besser mit PostgreSQL oder MySQL lösen? Brauchst du überhaupt einen OR-Mapper? Oder sind die Queries recht einfach und du kannst es selbst schnell in einer Klasse kapseln. Vielleicht gibts von Python auch zum ein oder anderen DBMS eine bessere Schnittstelle (OBDC-Treiber, o.ä.). Falsch machst du mit beiden Systemen sicherlich nichts.

  • Zitat von fyaa;35946

    Ich weiß gar nicht, wieso man SQLite verwenden möchte, wenn man nicht sehr ressourcenbeschränkt ist.


    Weil es "einfacher" ist?
    Ich habe mal für nen Kunden eine Anwendung geschrieben, deren Datenbankanforderungen minimalst waren, da habe ich dann auf die MySQL-Datenbankbank verzichtet mit dem Vorteil, dass die Installation kinderleicht war: man musste nur die ganzen Dateien per FTP hochladen und fertig, keine Datenbankverbindung einstellen, keine SQL-Datei importieren oder auch keinen Installer den man Schritt für Schritt durchgehen musste.

  • Zitat

    Ich weiß gar nicht, wieso man SQLite verwenden möchte, wenn man nicht sehr ressourcenbeschränkt ist.

    Nun ich würde behaupten es kommt immer darauf an was man machen will und wie die Vorraussetzungen sind. SQLite hat eben den Vorteil das man keinen Datenbankserver benötigt. Es gibt ja immer noch Anbieter die in günstigen Tarifen keine Datenbanken anbieten. Oder wenn wenn eine Anwendung local laufen soll kann der Datenbank Server auch entfallen.


    Zitat

    Weil es "einfacher" ist?

    Ich weiß jetzt nicht wie es bei php ist, bei Python habe ich jetzt aber keinen Unterschied feststellen können.


    SQLite

    Code
    import sqlite3  
    connection = sqlite3.connect("Datenbank.db")
    cursor = connection.cursor()
    cursor.execute("(CREATE TABLE lager (      fachnummer INTEGER, seriennummer INTEGER, komponente TEXT,      lieferant TEXT, reserviert INTEGER ") )

    MySQL

    Code
    conn = pymysql.connect(host='127.0.0.1', unix_socket='/var/run/mysqld/mysqld.sock' , user='USER', passwd='PWD', db='mysql')
    cursor = conn.cursor()
    cursor.execute("""CREATE TABLE Orte (Name TEXT,
                      Typ INTEGER, Text TEXT, Ausgang TEXT, Zusatz TEXT)""")

    Also ein Unterschied der extrem ausfallen würde gibt es da also nicht. Mir ist bei MySQL bis jetzt nur negativ aufgefallen das man anscheinend nicht ohne Tricks einen text als Primärfeld festlegen kann. Aber das ist eher unwichtig...


    Ich selbst habe jetzt leider bei SQLite das Problem gehabt das die Datenbank manchmal blockiert bleibt. Da ich als Webserver Karrigell nutze wird im Fehlerfall die Datenbank nicht mehr geschlossen, wenn also ein Fehler bei der Schreibanweisung auftritt bleibt die Datenbank auf ewig gesperrt... Vor allem wenn man gerade in der Entwicklung ist passieren doch häufig mal Fehler und das ist ärgerlich. Bei MySQL ist mir das noch nicht passiert. Es kann zwar mal beim Programmieren passieren das eine Verbindung zu Datenbank offen bleibt aber durch eine gute Fehlerbehandlung tritt das kaum noch auf und wenn doch werden die offenen Verbindungen nach einer bestimmten Zeit beendet.


    Aber für viele kleine Aufgaben denke ich mal kommt man mit SQLite ohne Probleme auch zum Ziel.


    Grüße