Oracle ist ein absoluter PITA in so ziemlich in allen Bereichen bis auf 3:
- Die Scriptsprache (PL/SQL) ist wesentlich besser als dieser schizophrene Krempel, den Sybase TSQL taufte. Ernsthaft, in PL/SQL weißt du immer was zurückkommt, in TSQL muss man aufpassen dass nict mehrere Resultsets von in einem script geöffneten Selects zurückkommen.
In PL/SQL ist ein einfaches Select, ohne Into-Clause, ein Fehler, ganz einfach. 
- Man kann als DBA auch Datenbanken von Drittanbietern sinnvoll tunen, da man Indizes auf Ausdrücke anlegen kann.
Wenn man also erkennt, dass bestimmte Ausdrücke in best. Tabellen sehr häufig verwendet werden, kann man für diese Tabelle Indizes dieser Ausdrücke anlegen.
Oracle wird dann autom. diese Indizes hernehmen, wenn es Sinn macht.
In MSSQL kann man das nur indem man berechnete Spalten hinzufügt, die aber wiederum die 3rd-Party App brechen lassen könnten.
- Oracle kann sehr gut Clustern, und ohne Cluster kann man nur so weit skalieren.
Der Oracle Client und so ziemlich alles was mit erzeugen und entfernen von DBs zu tun, ist unglaublich schmerzvoll.
Da ich als Entwickler von der eigentlichen
DB möglichst wenig zu tun haben will[1], ist es mir wichtig, dass ich zumindest während der Entwicklung
gar nix mit Oracle zu tun habe.
MSSQL ist hier sehr angenehm, da es einem einfach nie im Weg ist (Außerdem gibt es eine ganz gute Integration im VS2012).
Da Oracle (IMO) aber wesentlich bessere Cluster-Möglichkeiten hat, finde ich es für ausfallsichere und performance-kritische Produktiveinsätze geeigneter (wobei ich dank ORM eh alle 3 unterstützen kann, die Sinn machen:
MSSQL, Oracle, pgSQL)
Oracle kann beim Clustering ausfallsicher
und schneller, bei
MSSQL geht entweder eines von beiden, oder der DBA erwägt sich mit einem stumpfen Kochlöffel zu erstechen, damit der Schmerz nachlässt.
Das kann natürlich subjektiv total daneben liegen, da ich den
MSSQL CLuster nicht eingestellt habe, sondern nur die Wutschreibe höre konnte.
Ohne richtigeres Clustering kann man aber schwerlich skalieren, ist also IMO ein ganz wichtiges Kriterium.
SProcs und die Syntax der SProc-Sprache sind wohl eher ein Kriterium für Legacy-Apps (wer schreibt denn noch Sprocs, wenn er eh einen WCF oder WebApi Service baut?
)
Wenn SProcs gebaut werden sollen (warum auch immer), hat Oracle so dermaßen die Nase vorn, dass es nicht mehr lustig ist.
Mein Fazit hier ist:
MSSQL für die Entwickler. Für die Intergationstests und Produktiv könnte es auch Oracle sein.
Aber nur wenn es sich leistungstechnisch bezahlt macht. Außer natürlich man jmd vor Ort, der viel Erfahrung mit
MSSQL Clustern hat.
Schnee von Gestern sind IMO alle RDBMS irgendwo. Aber wir brauchen sie leider noch bis wirklich was besseres kommt.
Platzhirsch ist Oracle ganz sicher nicht mehr. Nur da wo es einen Haufen Legacy-Krempel gibt. (pgSQL und
MSSQL sind noch nicht so lange so gut wie sie es heute sind.)
Oracle ist eher das notwendige Übel wenn Failover + Performance ausschlaggebend sind.
[1]die wird von nHibernate erzeugt und damit erzeuge ich auch die Migrationen (wobei ich die natürlich genau anschaue
)