- Die meisten Webanwendungen benötigen eine dauerhafte Datenspeicherung. Deshalb ist es in der Regel sinnvoll, bei einer neuen Anwendung standardmäßig
Postgres zu wählen.
Warum nicht sqlite?
sqlite ist eine gute DB, aber die Daten werden in einer einzigen Datei gespeichert.- Das bedeutet, dass die Anwendung nur auf einem einzigen Gerät läuft.
- Für Desktop- oder Mobile-Apps ist das passend, für Websites jedoch oft nicht.
- Es gibt erfolgreiche Beispiele für Websites mit sqlite, aber meist nur dann, wenn die Betreiber ihre eigenen Server und ihre eigene Infrastruktur selbst aufgebaut haben.
- Möglicherweise verzichtet man damit auf automatische Datenbank-Backups der Plattform sowie auf die Möglichkeit, mehrere Application-Server zu konfigurieren.
Warum nicht DynamoDB, Cassandra oder MongoDB?
- Diese Datenbanken liefern starke Performance, bringen aber viele Voraussetzungen mit:
- Man muss genau wissen, was die Anwendung tun soll und welche Zugriffsmuster sie haben wird.
- Es muss nötig sein, auf sehr große Datenmengen zu skalieren.
- Man muss bereit sein, auf einen Teil der Konsistenz zu verzichten.
- Diese Datenbanken funktionieren ähnlich wie verteilte Hash-Maps. Deshalb muss Wissen über die Query-Patterns bereits in die Art einfließen, wie die Daten gespeichert werden.
- Wenn sich die Zugriffs- bzw. Query-Patterns ändern, muss unter Umständen der gesamte Datenbestand neu verarbeitet werden.
- Relationale Datenbanken können einfach Indizes hinzufügen, um Queries auszuführen, bei NoSQL-Datenbanken ist das schwieriger.
- Für analytische Queries sind sie ungeeignet.
- Wenn Studierende oder Berufseinsteiger MongoDB verwenden, werden sie wahrscheinlich Unterstützung brauchen.
Warum nicht Valkey?
- Diese als
Redis bekannte Datenbank ist vor allem als sehr effizienter Cache bekannt.
- Sie kann als primäre Datenbank verwendet werden, hat aber folgende Probleme:
- Alle Daten werden im RAM gehalten, was schnell ist, aber der verfügbare RAM ist begrenzt.
- Beim Datenmodellieren sind Kompromisse nötig.
Warum nicht Datomic?
- Wenn Sie das schon kennen, bekommen Sie einen „Goldstern“.
Datomic ist eine relationale NoSQL-Datenbank, die das Problem des "Up-front Design" nicht hat und einige elegante Eigenschaften besitzt.
- Sie speichert Daten nicht in Tabellen, sondern als EAVT-Paare (entity-attribute-value-time) und verwendet allgemeine Indizes.
- Beim Schreiben von Queries ist keine Abstimmung mit dem Autor nötig. Man fragt einfach die Datenbank zum jeweiligen „aktuellen Zeitpunkt“ ab. Neue Daten und sogar Löschungen (auch „Retractions“ genannt) entfernen frühere Daten nicht wirklich.
- Es gibt aber einige Nachteile:
- Sie funktioniert nur mit JVM-Sprachen.
- Außerhalb von
Clojure ist die API nicht besonders gut.
- Fehlermeldungen durch schlecht strukturierte Queries sind extrem wenig hilfreich.
- Es gibt kein mit dem SQL-Tooling-Ökosystem vergleichbares Umfeld, daher fehlt es an Werkzeugen.
Warum nicht XTDB?
- Clojure-Nutzer bauen viele Datenbanken.
- Es ähnelt
Datomic, hat aber folgende Eigenschaften:
- Es bietet eine HTTP API und ist damit nicht an die JVM gebunden.
- Queries sind auf zwei Achsen möglich: „System Time“ und „Valid Time“.
- Es unterstützt eine SQL API.
- Das größte Problem ist jedoch, dass es noch „frisch“ ist. Die SQL API kam erst letztes Jahr heraus, und vor Kurzem wurde das gesamte Storage-Modell geändert.
- Wird es in 10 Jahren noch existieren? Ob es langfristigen Support geben wird, ist unklar.
Warum nicht Kafka?
Kafka ist ein sehr guter Append-Only-Log und eignet sich für die Verarbeitung von Daten im TB-Bereich.- Wenn man mit Daten aus vielen Services, die von mehreren Teams betrieben werden, Event-Sourcing-artige Aufgaben umsetzen will, funktioniert es erstaunlich gut.
- Aber
- In kleinem Maßstab lässt sich das oft gut durch Tabellen in
Postgres ersetzen.
- Kafka-Consumer zu bauen ist fehleranfälliger, als man denkt, weil man letztlich seine eigene Position im Log nachverfolgen muss.
- Zusätzliche Infrastruktur muss betrieben werden.
Warum nicht ElasticSearch?
- Wenn Datensuche eine Kernfunktion des Produkts ist, dann ist ElasticSearch dafür gut geeignet.
- Man muss Daten per ETL aufbereiten und den gesamten Prozess verwalten, aber ElasticSearch wurde für Suche gebaut und macht das gut.
- Wenn Suche jedoch nicht die Hauptfunktion ist, reichen die eingebauten Textsuchfunktionen von
Postgres oft aus.
- Später kann man immer noch eine dedizierte Suchmaschine ergänzen.
Warum nicht MSSQL oder Oracle DB?
- Die eigentliche Frage, die man sich stellen sollte, lautet: „Ist es das Geld wert?“
- Nicht nur die Lizenzkosten zählen, sondern auch die Kosten des Lock-ins.
- Wer Daten in Oracle speichert, zahlt Oracle dauerhaft Geld und muss Entwickler kontinuierlich darauf schulen.
- Man muss sich praktisch für immer zwischen Enterprise-Features und seinem Geldbeutel entscheiden.
- Wenn man nicht ganz bestimmte Funktionen unbedingt braucht, sollte man es lieber vermeiden.
- Nicht verwenden, solange es kein Killer-Feature gibt, ohne das man mit MSSQL nicht leben kann.
Warum nicht MySQL?
- An dieser Stelle ist ein wenig Hilfe der Leser gefragt.
MySQL gehört Oracle, und einige Funktionen sind in der Enterprise Edition eingeschlossen.
- Natürlich wird
MySQL schon lange verwendet, und es gibt eine weit verbreitete kostenlose Edition.
- Ich halte
Postgres für die bessere Wahl, aber zu MySQL wären zusätzliche Informationen hilfreich.
Warum keine AI-Vektor-DB?
- Die meisten AI-Vektor-DBs sind junge Technologien und ihre Nutzung ist mit Risiken verbunden.
- Bei Geschäftsmodellen, die auf der AI-Blase beruhen, ist Vorsicht angebracht.
- Selbst wenn Ihr Geschäft nur der nächste AI-Grift sein sollte, reicht wahrscheinlich schon
import openai.
Warum nicht Google Sheets?
- Keine besonderen Nachteile. Wenn nötig, kann man es ruhig verwenden.
18 Kommentare
Firestore...
Solche Artikel, die das so kategorisch behaupten, sind meist Fehler, die Junioren machen..
Stattdessen gebe ich euch den niedlichen C von SV.
zzz
Da fällt mir irgendwie der Witz ein: Wenn man gute Informationen bekommen will, muss man provozieren … haha
Wie dem auch sei: Da die meisten Backend-Entwickler als Erstes mit PostgreSQL arbeiten, …
Ich glaube, dass Postgres die bessere Wahl ist, aber ich brauche zusätzliche Informationen zu MySQL
hahaha;;;;
Das eigentliche Problem mit MySQL Enterprise ist nicht die Lizenz, sondern dass selbst zahlende Kunden bei Ausfällen einen wirklich beschissenen Support bekommen.
Früher, als ein MySQL-Index beschädigt war und das System nicht mehr startete, haben wir Support angefragt, aber von Oracle kam im Grunde nur: Wenn ihr ein Support-Ticket aufmacht, bieten wir Telefonsupport an.
Am Ende hieß es auf Kundenseite, dass das so nicht geht, also mussten wir das Problem selbst lösen.
Statt sich auf Oracle zu verlassen und Enterprise zu nutzen, ist kostenlos am besten..
Warum nicht mariadb, impala, hive oder kudu?
Die Enterprise-Funktionen von Mysql sind eher Dinge, die man nicht unbedingt braucht, wie etwa ein eigener Connection Pool..
Wenn es wirklich Enterprise ist, ist es für Lastverteilung deutlich effektiver, statt das hier zu nutzen, davor lieber einen SQL-Proxy zu installieren.
Ich mag Pgsql, aber mysql nicht einmal anzuschauen und einfach nur „keine Ahnung, ist mir egal“ abzuziehen.. hahaha
Nehmen Sie einfach MySQL …
Und MariaDB?
Ein Beitrag, der das Zeug zu einer sehr großen Kontroverse hat...
Der Grund, SQLite zu verwenden, ist, dass es simpel ist und bei den meisten Größenordnungen einfach gut funktioniert.
Man kann es also erst einmal einfach mit SQLite umsetzen und später, falls nötig, ohne große Schwierigkeiten auf Postgres wechseln.
Der gelegentlich wieder auftauchende Lobgesang auf Postgres. Genießt es inzwischen einfach!
Verwendet einfach überall Postgres
PostgreSQL ist völlig ausreichend
Seit wann ist Postgres eigentlich cool geworden?
Hacker-News-Kommentare
Es gibt viele negative Meinungen über MongoDB, aber die meisten beruhen auf falschen Informationen
Vorteile von SQLite
Auf technische Mängel hinzuweisen, ist nicht sinnvoll
Gründe für die Migration von MySQL zu Postgres
Postgres unterstützt Zeittabellen nur unzureichend
Ich verstehe nicht, warum man SQLite verwendet
Entschuldigung für die falsche Erwähnung von Rick Houlihans Namen
Wichtig ist, das zu verwenden, was man kennt, und Nützliches bereitzustellen
MySQL ist wie Javascript
Postgres verfügt über mehr Werkzeuge, um die Datenkonsistenz aufrechtzuerhalten
=> Gibt es dafür vielleicht Beispiele?
Ein Nachteil von SQLite im Vergleich zu Postgres scheint zu sein, dass es keine Schemas unterstützt. Wenn es mehrere Dutzend oder mehr Tabellen gibt, ist es sauberer, die Tabellen nach Schemas getrennt zu entwerfen. Da SQLite das nicht kann, muss man alle Unterscheidungsmerkmale in die Tabellennamen packen.