Zunächst kann man bei einer Google Suche sagen wir "alt" das Ergebnis sein soll. Das ist sinnvoll da man inzwischen in der Tag mit alten Mist zugemüllt wird (gerade in der vergänglichen IT).
Nach Ausführung der Suche oben links "Tools" anklicken und in der erscheinenden Zeile statt "beliebige Zeit" einen passenden Zeitraum wählen (z. B. "letztes Jahr").
Alt ist das Thema - insbesondere RDBMS - auch überhaupt nicht.
Zwar wird ständig NoSQL/BigData geschrieen, aber ehrlich gesagt haben moderne SQL-Datenbanksysteme auch viele (nicht alle) Funktionen integriert.
Im Falle von PostgreSQL ist dies z. B. der HSTORE-Typ, der schon lange vor dem Begriff "NoSQL" die Möglichkeit zur Speicherung von Key=Value Paaren vorhanden war (HSTORE ist auch die Grundlage der JSON und JSONB-Typen die PostgreSQL seit 9.x besitzt und innerhalb der 9.x-er Versionen weiter ausgebaut wurde).
Am Ende gehe ich noch mal auf Detail zu NoSQL/BigData und meine Erfahrungen damit ein...im Zweifel überspringen, da es doch vom eigentlichen Thema abweicht.
Wie schon erwähnt gibt es den SQL-Standard und die verschiedenen Anbieter halten sich mal mehr oder weniger daran und unterstützen in der Regel auch nur eine Teilmenge (insbesondere bei neueren SQL-Standards).
Gefühlt ist PostgreSQL immer relativ nahe dran und hat als kostenloses Datenbank Managementsystem einen unerreichten Funktionsumfang (Replication, JSONB/JSON (JSONB erlaubt die Indexerstellung auf bestimmte Keys), XML, Volltextsuche, PostGIS als Geo-Erweiterung (wird von OpenStreetmap verwendet), Array, umfangreiche RegEx Funktionen, etc.).
Datentypen wurden ja oben schon verlinkt...aber hier dennoch noch einmal der Link auf PostgreSQL...
https://www.postgresql.org/docs/current/datatype.html
EDIT: Wegen der Maximallängen von Strings. Die folgende Variante solle man nicht nutzen (hat hier ein Kollege leider auch gerade gemacht):
CREATE TABLE xxx (
mytext VARCHAR(10) NOT NULL
);
Statt dessen sollte man diese Konstrukt verwenden:
CREATE TABLE mytable (
mytext VARCHAR NOT NULL,
CONSTRAINT mytable_mytext_max_length_check CHECK (LENGTH(mytext) <= 10)
);
Begründung:
Beide Varianten erzeugen das gleiche Ergebnis aber wenn man mal die Länge anpassen muss, dann ist nur der Check Constraint zu ändern und nicht die Tabellendefinition selbst.
Hat man eine richtig "große" Tabelle, kann das Sekunden bis Minuten dauern in denen die Datenbank blockiert ist (--> LOCK), weil der komplette Inhalt der Tabelle umkopiert werden muss (es mag DBs geben, bei denen das nicht das Fall ist).
Im Falle des Check Constraints muss nur der Constraint geupdated werden, was im Bruchteil einer Sekunde erledigt ist.
EDIT-END
Außerdem kann man bei manchen Datenbanken eigene Typen erstellen, was überaus hilfreich sein kann.
Ich habe bei meinem früheren Arbeitgeber einen Typ für "Öffnungszeiten" bzw. Spechzeiten von Arztpraxen erstellt.
Warum mag man sich vielleicht fragen...die Liste der Varianten verdeutlicht es glaube ich:
- Mo Vormittags von X bis Y
- Mo Nachmittag von X bis Y
- Di Vormittag von X bis Y
- [...]
Dazu pro Tag noch die Option "hat Abendsprechstunde" (nach Definition Öffnungszeiten ab 18 Uhr) Boolean Feld Ja/Nein.
Sprich man hätte 5 Spalten pro Tag (also Mo bis Fr + ggf. Sa möglicherweise auch So)
5x7 =
max 35 Spalten
Mit PostgreSQL Create Type wurde daraus
"eine Spalte" vom Typ "sprechzeiten", und mittels Trigger wurde das Flag Abendsprechstunde automatisch auf TRUE gesetzt wenn ein Wert ab 18:00 (Nachmittags bis) hinterlegt ist, sonst FALSE.
Alle Felder werden mit einem RegEx auf korrekten Inhalt überprüft dazu noch extra Checks und automatische Feldinhalte Ersetzung so das die "Bis Uhrzeit"nicht vor der "von Uhrzeit" liegt (18:00 < 12:00 = FALSE).
Intern verwendet PostgreSQL ein "Record" Konstrukt.
Mittels "sprechzeiten.mo_von_uhrzeit" greift man auf den Inhalt des Feldes Montag Vormittag ab X Uhr zu.
Mit dem XML-Typen in PostgreSQL habe ich gerade mit ein paar Zeilen SQL den Inhalt der ISO-Currency Codes (XML) in ein vernünftiges Tabellenformat importiert (1. CREATE TEMPORARY TABLE temp_currency....ON COMMIT DROP; 2. COPY FROM xxx --> temp_currency; 3. INSERT INTO iso4217_currency_detail SELECT xxx_viele_xpath FROM temp_currency ). Statt dies in einem SQL-Skript zu machen, wie ich es nun initial vorgenommen habe, kann man auch eine Funktion verwenden, was den Vorteil hat, das man den Pfad zu XML-Datei beim Funktionsaufruf mitgeben kann und bis zu einer Änderung in der XML-Format einfach die Daten aktualisieren kann (es gibt zusätzlich eine Versionspalte und ein aktiv-Flag, so dass man dafür sorgen kann das immer nur die aktuellen Daten aktiv und vom Benutzer auswählbar sind).
NoSQL/BigData
Persönlich sehe ich NoSQL/BigData kritisch, da NoSQL meistens nur das Problem sich eine ordentliche Datenstruktur zu überlegen auf den Entwickler abwälzt und dieser in der Regel die "für den Augenblick" einfachste Lösung zu werden (im Zweifel alles in einen JSON String werfen und in einer Spalte ablegen).
Das Problem ist am Ende häufig das es keine ausreichende Validierung bei den Daten gibt und die Strukturen wieder umgeworfen werden (hätte man auch gleich ordentlich machen können...am Ende "günstiger"). Grundsätzlich sollte das Prinzip sowie lauten "Trust nobody" und validiere jedes Feld - auch Kombinationen (Beispiel Geokoordinaten lat/long; beide ungültig wenn nur ein Wert aus dem Range läuft).
Wer hat schon BigData und ab wann kann man das überhaupt so bezeichnen.
Hier ist NoSQL auch nicht unbedingt die Lösung, dann auch mit Relationalen Datenbanksystemen können wirklich große Datenmengen verwaltet werden.
PostgreSQL und auch andere RDBMS können problemlos mehrere Millionen oder Milliarden Datensätze speichern und durchsuchen (auch schnell). Das Stichwort lautet "Partitionierung" von Daten (z. B. Aufteilung nach Zeiträumen). Dann werden selbst sehr große Datenmengen handhabbar. Es gibt sicher Randfälle in denen man auch hier an Grenzen kommen kann aber das dürften Spezialfälle sein (z. B. Google Suche).
Ähnlich ist es übrigens mit der Volltextsuche. Solr wird gerne genommen, aber ist es überhaupt nötig? Es erhöht die Komplexität (noch ein System zu warten + noch ein System das ausfallen kann). Daten können erst durchsucht werden wenn die Indizierung durch ist, was durchaus dauern kann, während die Datenbank Volltextsuche vermutlich schon reicht und instant den Index aktualisiert.
Ich habe bei einem größeren Projekt bereits eine Umstellung von MySQL (Cluster; 5 MySQL Instanzen) + Solr auf eine einzige PostgreSQL Instanz mit Volltextsuche vorgenommen. Dazu wurden einige Prozesse, die sich in der Vergangenheit als "Fehlertor" erwiesen ausgemerzt (Geodaten) und die Datenverarbeitung ging ohne Solr X-fach schneller bzw. war sofort nutzbar, während man zuvor noch Stunden auf die Solr-Indizierung warten musste. Dazu wie gesagt noch die Einsparung eines MySQL Clusters.
Die Daten konnte per großem SQL-Skript ohne den zuvor nötigen Umwege über ein XML-Austauschformat (noch ein Fehlerteufel im alten System) direkt in das für das Portal nötige "abfrageoptimierte" Tabellenschema überführt werden.
Das System läuft immer noch, aber jetzt war tatsächlich mal ein Update des Servers nötig, da weitere Daten dazu gekommen sind und der alte Server so langsam an die Grenze kam. Zusammen mit den neuesten PostgreSQL Erweiterungen aus v10+ (parallele Queries) kann man mehrere Kerne besser ausnutzen kann. Sollte auch das nicht reichen, wird die Replizierung angeworfen und man verteilt lesende Queries auf den Slave (Standby-Server).
Aber sonst fällt mir da auch nichts ein.