Oracle – Das fettere MySql

Seid gut 5 Jahren setze ich als RDBMS für kleine und große Projekte PostgreSQL ein. Es lässt sich schnell installieren und hat mir bisher noch jeden Wunsch von der Kommandozeile abgelesen. Bildlich stelle ich mir PostgreSQL als eine stabile Softwarelösung vor, bei der sich die Entwickler viele Gedanken um die ideale Umsetzung machen.

Zuvor habe ich mich etwa ein halbes Jahr im MySql-Umfeld bewegt. Wer es nutzen möchte kann dies natürlich tun, auf mich macht das irgendwie einen wackeligen Eindruck. Vor allem dann, wenn ich an das 5.1er-Release denke. (Schimpft ruhig in den Kommentaren, so bekomme ich wenigstens welche.)

Dank des aktuellen Projektes habe ich das große Glück in das so angepriesene Oracle reinschnuppern zu können. Selbstverständlich könnte ich das auch in meiner Freizeit, doch lagen meine Interessenschwerpunkte bisher auf anderen Gebieten. Meine ersten Kontakte mit Oracle haben mich auch gleich wieder zurückschrecken lassen, weshalb ich nun nach drei Wochen leider noch sehr weit vom Oracle-”Fachmann” entfernt bin.

Kritik an etwas zu äußern, womit man sich nicht auskennt, ist ja immer eine heikle Angelegenheit und sollte grundsätzlich unterlassen werden. Von der anderen Seite betrachtet könnten sich daraus aber neue Erkenntnisse entwickeln, die mir vielleicht helfen Oracle unter einem anderen Licht zu sehen. Konstruktive Hinweise heiße ich daher herzlich willkommen.

Installation

Begonnen hat alles mit der Installation von Oracle Database 11g, was mich etwa 8 Stunden gekostet hat. Ich weiß bis heute nicht, ob ich überall richtig geklickt habe. Es ist auch aus meiner Sicht fraglich, warum es sich per Default nach /u01 installiert, man stelle sich vor das würde jede Anwendung machen. Zumindest die nach der Installation belegten 3.18 GB sollten einen nicht stören, wenn sich die in der Datenbank zu haltende Datenmenge im Terrabytebereich bewegt. Wenn ich mich nicht total irre, hatte mir das Web-Interface mitgeteilt, dass die Datenbank-Daten um die 2.5 GB belegen. Was halten die da bitte für Daten?

SQL

Wenn ich das richtig sehe, baut Oracle auf ein paar wenigen Grunddatentypen auf und mappt die Standard-Datentypen darauf. Das hat zur Folge, dass aus einem INT ein NUMBER(38) wird und aus einem SMALL ebenfalls eine NUMBER(38). (BOOL übrigens auch.) Die 38 steht dabei für die Anzahl der Ziffern, die vor dem Komma stehen können.

Oracle scheint auch mit Leerzeilen innerhalb eines Statements nicht klar zu kommen.

Auch, wenn es die hohe SQL-Schule nicht gut heißt, kommt doch häufig eine fortlaufende Nummer als Primärschlüssel zum Einsatz. Vor allem dann, wenn eine größere Anzahl an Attributen zu einem Primärschlüssel zusammengefast werden müsste, um die Eindeutigkeit herzustellen. Auf die Möglichkeit der Auto-Generierung muss man in Oracle leider verzichten. Wer das dennoch möchte findet viele Anleitungen zur manuellen Erstellung der Trigger. So ein Datenbanker soll ja schließlich auch was tun für sein Geld.

Einen schönen Überraschungseffekt erlebt man, wenn man nicht weiß, dass grundsätzlich alles in einer Transaktion läuft. Wer sich also wundert, warum das SELECT beim einen Client die frisch eingefügte Zeile anzeigt und beim anderen nicht, sollte zunächst COMMIT ausführen. Ich finde es irgendwie abwegig nicht extra über TRANSACTION darauf hinzuweisen, dass man in einer ist.

Interessiert man sich nur für die ersten drei Zeilen eines SELECTs, bieten einem MySql und PostgreSQL das Schlüsselwort LIMIT. Oracle hingegen führt als eine Art verstecktes Attribut die Zeilennummer mit, welche in der WHERE-Klausel mit einer Bedingung verknüpft werden kann. Wenn man nun die drei besten Ergebnisse haben möchte, darf man das zweite SELECT nicht vergessen.

SELECT * FROM (
   SELECT points FROM MIKANE ORDER BY points DESC
) where rownum <= 3

Gegen Oracles Fehlermeldungen kann man ja fast gar nichts sagen. Zwar wären die Fehlerursachen auch was für den Post, aber zumindest die nummerierten Fehlermeldungen führen einen, dank der Dokumentation, meist zu Lösung. Hin und wieder darf aber gerätselt werden, wenn man Fehlermeldungen liest wie: “line %s, column %s:\n%s”.

Client

An dieser Stelle möchte  möchte ich nicht über den Standard-Kommandozeilen-Client sqlplus meckern. Das Ding sollte man einfach nicht verwenden.

Ziel war es sich über C++ mit Oracle in Verbindung setzen, wobei ich hoffte, die Einbindung des Oracle-Treibers OCCI würde genügen. Grundsätzlich ist das auch völlig ausreichend, wenn man seinen Client auf der gleichen Maschine laufen lässt, wo sich auch die Oracle-Installation befindet. Möchte man diesen Client von seinem kleinen Entwickler-PC aus verwenden, benötigt man eine Oracle-”Mini?”-Installation.  Damit habe ich mich bisher leider nicht näher beschäftigt (Zeitmangel). Wenn ich richtig informiert wurde, wird die Installation benötigt, damit der Client die Datenbank über die Oracle-Eigene Namensauflösung findet.

Fazit

Wenn ich mir meinen eigenen Text zu durchlese, könnte man sich an das meiste eigentlich gewöhnen. Dass viele Dinge in anderen Systemen anders laufen liegt ja in der Natur der Sache. Allerdings bleibt Oracle meiner Ansicht nach eine Datenbank für extrem große Projekte. Damit meine ich so richtig riesen groß und überdimensioniert. Genau genommen habe ich auch diese Features, die sie angeblich für Großprojekte geeignet machen, noch nicht berührt. Da vertraue ich einfach mal auf die Leute die es einsetzen und davon überzeugt sind. Für Projekte in meinen Größenordnungen habe ich allerdings noch nichts entdeckt, was PostgreSQL nicht auch (effektiver) erschlagen würde.