Ich möchte jetzt nicht über Hierarchische Datenbanken, Netzwerk Datenbanken oder anderen Formen, mit denen ich während des Studiums vor 30 Jahren konfrontiert worden bin, schreiben.
Manchmal hatte ich mit IBM IMS-DB, also einer Hierarchischen Datenbank, in Projekte zu tun, weil es noch eine Anwendung mit langer Historie gab, aber es war die Ausnahme.
Die „neuen“ NoSQL Datenbanken sind interessant, wenn man grosse Datenbestände eindampfen möchte, um in Realtime Auswertungen auf riesige Datenbestände fahren zu können. Das sind neue, interessante Anwendungen, aber eher Nischen.
Jedes Unternehmen hat Buchhaltungs-, Kundenstamm-Daten und Kontobewegungen und das Finanzamt wird sich bei einer Betriebsprüfung nicht mit den „eingedampften“ Daten, sprich das Buchhaltungsjournal wurde zur die Bilanz verdichtet, zufrieden geben.
Eine sehr gute Methode, die Daten physikalisch zu speichern, ist das Relationale Datenbank-Modell.
Eine Datenbank ist etwas, was Transaktionen bereitstellt, also ACID. Weiterhin stellt eine Datenbank als Abfrage-Sprache (DML) und Definitions-Sprache (DDL) SQL zur Verfügung. Andere DML / DDL gab es, aber es hat sich SQL als Standard herausgebildet.
MySQL wird meist mit der Storage-Engine MyISAM verwendet, insbesondere bei CMS oder ähnlichen Anwendungen steht das schnelle Lesen im Vordergrund, geschrieben wird hier wenig, deshalb ist ACID nicht wichtig. Falls ACID benötigt wird, gibt es andere Storage-Engines (InnoDB).
Vor 25 Jahren gab es einige kommerzielle Relationale Datenbanksysteme (ADABAS, SyBase, Informix, SESAM, …). Viele dieser DBMS sind heute noch verfügbar, wurden bei meinen Kunden in den letzten Jahren aber nur selten bei neuen Projekten verwendet.
Heute gibt es einige OpenSource DBMS. An erste Stelle ist MySQL zu nennen. Hiervon gibt es einige „Abspaltungen“, nach dem Oracle MySQL beim Kauf von SUN übernommen hatte. Andere bekannte OpenSource DBMS sind PostGre oder Derby.
Es gibt auch einige sehr kompakte OpenSource Datenbanken, zum Beispiel SQLite. Mein TV-SAT Receiver verwendet diese Datenbank, ob mit SQLite sinnvoll ein Mehrbenutzer-Warenwirtschaftssystem zu betreiben ist?
In der Microsoft Welt ist der MS SQL-Server von Bedeutung, MS-Access ist eher eine Desktop Datenbank.
Im kommerziellen Umfeld unter den Betriebssystemen Linux, Unix und auch z/OS sind primär zwei DBMS zu finden, Oracle und IBM DB2. Mit diesen beiden Systemen arbeite ich seit über 20 Jahren, da die meisten meiner Kunden auch IBM z/OS einsetzen, mit Schwerpunkt IBM DB2.
Bei der Sprache SQL gibt es einen ANSI-Standard. In der Regel wird in der Anwendungsentwicklung hiervon auch nur ein Subset genutzt.
Ich nutze SQL recht intensiv, DML Statements mit mehreren hundert Zeilen, Common Table Expressions, Scalar Funktionen, Expressions, Outer Joins über einige Tabellen, … Aber ich habe keine Schalter „DB2 / Oracle“ im Kopf, in den letzten Jahren sind mir keine Unterschiede zwischen Oracle und DB2 SQL aufgefallen. Sicher, früher gab es den sehr alten Oracle Syntax für Outer Joins (das „+“), aber Oracle hat sich den ANSI-SQL angepasst, und IBM hat vieles der Oracle DML in seine Datenbank eingebaut.
Vor einige Jahren meinte ein Entwickler bei einem Gespräch, dass es doch einen Unterschied zwischen DB2 und Oracle gibt. Er war gerade dabei, eine COBOL Anwendung von z/OS, IBM COBOL und DB2 auf Linux, MicroFocus COBOL und Oracle zu portieren. Beim Format der Timestamps in COBOL gibt es einen Unterschied.
Bei der alten Version auf dem Mainframe mit DB2 steht , bei der neuen Version mit Oracle aber “2015-03-15 16:04:05.123“.
Dabei störte ihn wohl nicht die letzten 3 Stellen. Wenn die Datenbank über 1000 Transaktionen pro Sekunde schafft und der Timestamp weiterhin eindeutig bleiben soll, sind die zusätzlichen Stellen notwendig.
Arbeit machte das Leerzeichen statt des Bindestrichs zwischen Tag und Stunde und vor allem die Doppelpunkte statt dem Punkt zwischen Stunde, Minute und Sekunde.
Das Problem wäre auch aufgetreten, wenn er statt einer Oracle Datenbank eine IBM DB2 (egal of z/OS oder Unix) genommen hätte.
Der Grund ist der ODBC-Treiber, den MicroFocus wohl nutzt. Die Umsetzung des SQL Datentype Timestamp ist bei ODBC etwas anders definiert.
Greift man per JDBC, also der Java-Variante von ODBC, auf eine Orcale oder DB2 Datenbank zu, kommen die Timestamps wie erwartet im ODBC Format, also die Version mit den Doppelpunkten, greift man per SPUFI (also z/OS 3270 Terminal) auf die gleiche DB2 Datenbank zu, sieht man die Punkte.
Welche der beiden Datenbank genutzt wird, ist sicher abhängig von der Plattform und den Lizenzkosten. Aber aus der Sicht eines Entwicklers sind die SQL Statements kompatible.
Es gibt sicher Möglichkeiten in DB2 und vor allem Oracle, die sich so nicht bei dem anderen DBMS nutzen lassen, aber dazu muss sich der Entwickler anstrengen und er sollte dafür gute Gründe haben.