Postgre beste Datenbank!

[triplekiller]

Hatte bis jetzt nie Probleme damit. Aber SQLite, MySQL und MariaDB sind auch sehr gut.

[FieteMax]

Müsstest du dann nicht quadruplekiller heißen?

[JouMxyzptlk]

Meine Erinnerung sagt dass es ab vier einfach nur noch Multikill heißt.
https://www.youtube.com/watch?v=ZFegCQ_7Mug

[andruman]

es heißt postgres oder postgresql...nicht postgre(fragt mich nicht wieso)
mysql ist aus DBA-Sicht ein räudiges Datenbanksystem. bequem für Entwickler weil Zeug funktioniert das nicht funktionieren sollte. Ich rate jedem der eine Datenbank benötigt zu postgres.

[mars96]

andruman schrieb:
--------------------------------------------------------------------------------
> mysql ist aus DBA-Sicht ein räudiges Datenbanksystem. bequem für Entwickler
> weil Zeug funktioniert das nicht funktionieren sollte. Ich rate jedem der
> eine Datenbank benötigt zu postgres.

Dem kann ich nur zustimmen.

Es stellt sich sowieso die Frage wieso man nicht gleich zu PostgreSQL greift. Eine halbwegs ersthafte Anwendung sollte meiner Meinung nach jedenfalls PostgreSQL unterstützen.

Die Installation ist genauso simpel (oder kompliziert) wie bei MySQL (und dessen Klon MariaDB). Wirklich schneller ist MySQL auch nicht (jedenfalls nicht wenn man etwas auf konsistente Daten gibt).
Wer will kann auch bei PostgreSQL schrittweise alles abschalten was dafür sorgt das die Daten gesichert in die Tabellenstruktur geschrieben werden (Verzicht auf Transaktionen, fsync,...). Das geht maximal bis zur "In-Memory" Datenbank (= Strom weg, Daten weg; Anwendungsfälle sind durchaus denkbar).

Dazu hat PostgreSQL einen SQL-Funktionsumfang der den von MySQL übersteigt und sich mit den "vermeintlich" professionellen (!=besseren) DBs wie Oracle (teilweise den zusätzlichen Funktionsleveln gegen jede Menge Geld), DB2 und MS SQL-Server messen kann.
Dabei sollte man bedenken das man hier von einer "kostenlosen" Datenbank redet und nicht etwas das mit jährlichen 5-6 stelligen Betrag eingekauft wird (im Extremfall auch Mio-Beträge...kenne da auch Beispiele).
Wer Support braucht kann sich diesen auch kaufen und wird trotzdem nur einen Bruchteil eines Oracle Lizenzbetrages über den Tisch schieben.

Ein kleiner Teil der z.B. bei Oracle kostenpflichtig einzukaufenden Features ist zugegebenerweise auch erst mit den letzten PostgreSQL v9.x Versionen dazu gekommen oder erweitert worden (insbesondere Verbesserung der Replizierung oder JSON/JSONB).

Hier mal eine kleine Auflistung von Features:
* Replizierung out of the box (wurde mit den PG 9.x Versionen deutlich ausgebaut)
* JSON und JSONB (hier insbesondere die Indizierung)
* HStore (Key-Value Store; gibt es schon ewig aber es wird bzw. wurde wenig genutzt; es ist die technologiesche Basis der JSON/JSONB Erweiterung)
* Mengenoperationen (SQL: UNION, INTERSECT, EXCEPT,...)
* Array-Unterstützung (kann direkt mit SQL abgefragt werden; kein PHP-Array mit z. B. IDs in einer Text-Spalte, wie man es gerne in der PHP/MySQL Gemeinde findet, weil ein Pfuscher am Werk war, der keine Lust auf eine Mapping-Tabelle hatte...dumm nur wenn man plötzlich mit Java oder einer anderen Sprache die Daten aus der MySQL Tabelle abrufen möchte und erst mal das PHP-Array "interpretieren" muss, um die Daten aus einer weitere Tabelle abfragen zu können)
* selbstdefinierte Datentypen (CREATE TYPE person_kontaktdaten AS (titel varchar, vorname varchar, ...); -- kann man wie jeden anderen Datentypen in einer Spalte oder auch einem Array speichern)
* mächtige Volltextsuche mit Gewichtung, erweiterbar um einene Wörterbücher, etc. (Links zu Beispielen folgen weiter unten) und schon ewig mit Transaktionssicherheit möglich (im Gegensatz zu MySQL das bis vor rund 3 Jahren nur mit MyISAM Backend eine Volltextsuche geboten hat und dann eine InnoDB Vollstextsuche mit zunächst erschreckend üblen Bugs so das es unvollständige/falsche Ergebnisse gab)
* Volltextsuche^2 mit der simplen wie nützlichen Funktion "ts_stat(..)"; Damit kann man sich einfach mittels SQL-Query Informationen zum Volltext Index holen (Liste von Wörtern und deren Häufigkeit), die man auch schön zur Erstellung einer Lookup-Liste mit Gewichtung (Priorität) verwenden kann. MySQL bietet soetwas leider nur eine eine Executable, nicht jedoch direkt für die Verwendung in einem SQL-Befehl.
* RegEx in Abfragen (WHERE ... Abschnitt) und auch RegEx zur Manipulation von Werten in aus Spalten "out of the box" (SELECT ... Abschnitt) (MySQL hat nur eine rudimentäre Unterstützung, für den Rest müssen Erweiterungen installiert werden; die PostgreSQL RegEx-Implementierung könnte man vermutlich noch etwas beschleunigen)
* Geodaten Verwartung mit der zusätzlich zu installierenden Extension PostGIS (PostgreSQL + PostGIS kommt seit einigen Jahren bei OpenStreetmap zur Anwendung, wo es übrigens MySQL abgelöst hat)
....

Wer mehr zur Volltextsuche in PostgreSQL erfahren möchte sollte sich mal die folgenden Artikel ansehen:
* PostgreSQL Full Text Search Is Often Good Enough (2011-04)
von Scott Lowe
http://www.scottlowe.eu/blog/2011/04/28/postgresql-full-text-search-is-often-good-enough/
* Postgres full-text search is Good Enough! (2015-07)
von Rachid Belaid
http://rachbelaid.com/postgres-full-text-search-is-good-enough/
* POSTGRESQL: A FULL TEXT SEARCH ENGINE (2014-04+)
von Tim van der Linden
Hier geht es so richtig ins eingemachte....
http://shisaa.jp/postset/postgresql-full-text-search-part-1.html
http://shisaa.jp/postset/postgresql-full-text-search-part-2.html
http://shisaa.jp/postset/postgresql-full-text-search-part-3.html

Ich selber unterstütze bei den von mir geschriebenen Anwendungen neben PostgreSQL auch MySQL und SQL Server inkl. Volltextsuche (Oracle, DB2, etc. sind in Teilen berücksichtigt aber in der Regel nicht für den Endnutzer verfügbar).
Es ist manchmal wirklich schmerzhaft eine einfache Funktionalität in MySQL oder auch SQL Server umzusetzen, die einem in PostgreSQL häufig geschenkt wird, ohne das man sich eine Funktion im Code (oder ggf. in der Datenbank: PL/SQL,...) schreiben oder andere "Klimmzüge" machen muss.

Ende November war ich in Hamburg auf der PostgreSQL Konferenz. Verglichen mit anderne IT-Konferenzen war es sehr günstig und damit auch für die Personen geeignet die mal über den Tellerrand schauen möchten.
Neben den technischen Vorträgen war es auch interessant den Migrationsprojekten zu lauschen.
Eines betraf the Umstellung von "Elster". Ja, unsere lieben Steuereintreiber in Bayern (die Bayrische Finanzdirektion ist hier verantwortlich), hat das Elster System von Oracle auf PostgreSQL migriert, was offenbar recht problemlos abgelaufen ist.
Die Daten sind verschlüsselt und das die Datenmenge nicht gerade klein ist dürfte bei der Einwohnerzahl Deutschlands wohl auch selbsterklärend sein, auch wenn natürlich nicht jeder Bürger hier mit einem Datensatz vertreten ist.


Wer noch etwas MySQL Bashing wünscht wird hier fündig... ;)
http://shisaa.jp/postset/mailserver-2.html

[Bitschnipser]

Das ist die Sicht des Anwendungsentwicklers.
Als Anwendungsentwickler kann ich die eigentlich nur komplett unterschreiben. Für Anwendungen ist Oracle nicht so doll - außer vielleicht bei der Performance, und auch da gibt's eigenartige Effekte.

Für den Administrator hat Oracle durchaus Vorteile. Behaupten jedenfalls die Oracle-Verfechter. Zuletzt wurden mir insbesondere replizierter Betrieb und Tabellenpartitionierung entgegengehalten, außerdem Backup im laufenden Betrieb.
Und soweit die Features da waren, ging es dann in die Details dieser Features, wo dann Postgresql doch noch nicht alles hatte.