Welche DB? mySQL, MS-SQL, Oracle ...

[Jasocul]

Hallo DB-Spezialisten,

bei uns gibt es Planungen, das Datawarehouse komplett neu aufzubauen. Es stellt sich dabei auch die Frage, welche DB wir einsetzen wollen. Derzeit ist MS-SQL für das DWH im Einsatz. Wir nutzen für andere Bereiche auch Oracle. Wir sind aber grundsätzlich offen für andere DB-Systeme.
Ich habe schon einiges im Internet recherchiert, um Unterschiede zu ermitteln, aber das sagt oft wenig über den Einsatz in der Praxis aus und ob die Infos wirklich aktuell oder subjektiv gefärbt sind, kann man auch nicht immer beurteilen. Für die, bei uns eingesetzten Systeme, kann ich das natürlich einschätzen. Für potentielle Alternativen nicht unbedingt.
Aktuell steht noch mySQL bei mir zur Debatte. Für weitere Alternativen bin ich aber offen.

Bei dieser Betrachtung soll der Preis erstmal Nebensache sein. Natürlich spielt der im Endeffekt auch eine Rolle, wichtig sind aber erstmal die technischen Merkmale.

Bei mySQL habe ich unter anderem gefunden, dass es keine Benutzergruppen und Rollen gibt. Das kann bei Berechtigungskonzepten zu erheblichem Mehraufwand führen. Das Locking soll abhängig von der Storage-Engine sein. Beim Backup dürfen angeblich keine Abfragen parallel laufen. Ist dann blöd, wenn man mal eben eine Arbeitskopie erstellen möchte. Restoring soll auch sehr zeitaufwendig sein. Das sind alles keine Killerargumente für mySQL, aber schon Einschränkungen, die Mehraufwand bedeuten können.

Es wäre schön, wenn ich einige Infos aus der Praxis bekommen kann. Wie geschrieben, sind wir für weitere Alternativen immer noch offen. SQL99 muss aber mindestens unterstützt werden.

[haentschman]

Moin...8-)

Datenmengen? Anzahl gleichzeitiger User? Texte, Zahlen, Blobs? Größe MSSQL Current? :wink:

[Jasocul]

Ups, da habe ich doch wichtige Fragen offen gelassen.
Datenmengen: Teilweise Tabellen mit Datensätzen im 2-stelligen Mio-Bereich. Das meiste aber unter 500 Tsd
Anzahl Concurrent-User: aktuell ca. 50. Tendenz steigend und nach der Umstellung ca 150-200.
Datentypen: Vorwiegend Zahlen und Text. BLOB nur in sehr geringem Umfang.
Aktuelle DB-Größe: ca. 170 GB

[philipp.hofmann]

Kleiner Hinweis zu mySQL und dem Thema: "Das Locking soll abhängig von der Storage-Engine sein"

-> das ist manchmal ein entscheidender Vorteil; nicht für alle Daten braucht man Transaktionssicherheit und die Performance ist ohne Transaktionssicherheit nun mal schneller; es gibt z.B. in meinem Umfeld oft Daten, die eh einmal am Tag komplett neu geladen werden und dies soll schnell gehen; wenn es hier Probleme gibt, ist es einfacher die Daten neu zu laden als über irgendwelche Transaktions-Rollbacks die Daten wiederherzustellen; bei Oracle und MS-SQL bedeutet dies, dass du über SQL-Loader oder bcp (BulkCopy) gehen muss (also sehr nah an jeweiligen DB programmierst und optimierst), bei MySQL kannst du dies auch mit SQL-Mitteln lösen, weil du für die betroffenen Tabellen dann eine auf Performance optimierte Storage-Engine wählst;

Wenn du mySQL in Betracht ziehst, solltest du aber auch einen Blick auf MariaDB werfen, weil dies die OpenSource-Variante zu MySQL ist, welche ja mittlerweile Oracle gehört und auch bei MySQL fallen je nach Einsatzzweck Lizenzgebühren an. Aber deine Größenordnung sieht schon so aus, dass eine DB mit dementsprechendem Support sinnvoll sein sollte.

[Jasocul]

Zitat:

Zitat von philipp.hofmann (Beitrag 1471476)

Kleiner Hinweis zu mySQL und dem Thema: "Das Locking soll abhängig von der Storage-Engine sein"

-> das ist manchmal ein entscheidender Vorteil; ...

Stimmt, das kann durchaus auch ein Vorteil sein. Gerade im DWH-Bereich kommen solche Aktionen schon mal vor.

Zitat:

Zitat von philipp.hofmann (Beitrag 1471476)

Wenn du mySQL in Betracht ziehst, solltest du aber auch einen Blick auf MariaDB werfen,

Bin ich vorhin auch drüber gestolpert. Ich hatte von MariaDB auch schon gehört, aber bei meinen Recherchen nicht mehr daran gedacht. Die hat schon Einiges, was ich bei mySQL vermissen würde.

[haentschman]

Zitat:

bei uns gibt es Planungen, das Datawarehouse komplett neu aufzubauen

...die Frage ist...wieso? :gruebel: Never touch a running system. :wink:

[Jasocul]

Zitat:

Zitat von haentschman (Beitrag 1471484)

Zitat:

bei uns gibt es Planungen, das Datawarehouse komplett neu aufzubauen

...die Frage ist...wieso? :gruebel: Never touch a running system. :wink:

Es gibt zum Teil komplette Software-Systemwechsel, bei denen die jetzigen Strukturen des DWH nur noch mit hohem Aufwand unterstützt werden können. Außerdem genügt das DWH nicht mehr den Anforderungen an der Granularität der Daten. Das System muss also sowieso im erheblichen Umfang angefasst werden. Das Projekt ist auch in einem zeitlichen Rahmen von 1 bis 1,5 Jahre umzusetzen. Der Aufwand ist uns also durchaus bewusst. :wink:

[Medium]

Zitat:

Zitat von Jasocul (Beitrag 1471482)

Bin ich vorhin auch drüber gestolpert. Ich hatte von MariaDB auch schon gehört, aber bei meinen Recherchen nicht mehr daran gedacht. Die hat schon Einiges, was ich bei mySQL vermissen würde.

MariaDB ist der Fork von MySQL, den der ursprüngliche Entwickler nach der Übernahme von Oracle eigenständig weiterentwickelt. (Benannt nach seiner 2. Tochter, die erste heißt My - ist nicht Englisch zu verstehen!) Seit Oracle MySQL besitzt, ist die Lizenzpolitik recht unübersichtlich. Insbesondere bei Nutzung der libmysql.dll zum Zugriff, bzw. "insbesonderer" bei Nichtnutzung dieser, sondern nativem Zugriff mit z.B. UniDAC ist unklar ob und welche Gebühren anfallen. Zumindest war es so, als ich mich das letzte Mal damit beschäftigt hatte. MariaDB geht dem komplett aus dem Weg, und ist bzgl. Zugriff voll zu MySQL kompatibel.
Wir setzen MariaDB seit einigen Jahren sehr erfolgreich ein, sind aber auch keine DBMS "Poweruser". Zumindest kann ich sagen, dass auch Tabellen mit mehreren Millionen Sätzen performant verarbeitet werden können wenn man sich nicht allzu blöd anstellt. Was aber Management und Toolsets angeht, ist man hier vermutlich deutlich spartanischer unterwegs als bei den großen kommerziellen Varianten. Bei der Größenordnung die du nennst, und besonders der Nutzeranzahl, könnte es doch sinnvoll sein in ein DBMS nebst Herstellersupport zu investieren. Hier kann ich aber keine Erfahrungswerte anbieten.

[HoppyP]

Woran hapert es bei der aktuellen Lösung? Wo zwickt es?

Der MS-SQL Server deckt so ein breites Spektrum ab, sodass keine typischen oft wiederkehrende Sammlung von Szenarien allein aus der Information ableitbar ist.

Fragen angelehnt aus der Perspektive einer ausgewachsenen Data-Warhouse Architektur in der sich oft Anforderungen auch im kleineren Maßstab wiederfinden.

a) Läuft die Steuerung/Monitoring von Jobs über das OS oder in einer eigenen Software oder im Rahmen eines wie auch immer gearteten integrierten Reporting/Staging/ETAL Werkzeug ala. QlikView & Co.

b) 24*7?

c) Gibt es eine Trennung zwischen Administration Infragstruktur, Systementwicklung, Wartung und Business Support.
c1) Verwenden Entwickler und Support für AdHoc Abfragen bspw. SQL Erweiterungen als Oracle CUBE Queries oder MSX im Falles des SQL-Server
c2) Wollt ihr euch auf bspw. Materialized Views & Co einlassen

Habt ihr von der Datenbeschaffung bis zur Auswertung hin alles selbst geschrieben und könnt frei wählen. Ich mache es nur mehr so. Was am OS geht geht wird am OS gemacht, was geht auf der DB und tunlichst für Änderung und Ergänzung des Werkzeugkastens für die Auswertenden. Sprich es sollte möglich sein für ein anderes Werkzeug die Daten nach dem ODS abzuzweigen und passend aufzubereiten.

Am kompaktesten ist der SQL Server. Ich euch der SQL-Server 'zu groß' zu umfangreich oder zu klein und wenn ja welche der mächtigeren Features einer anderen DB als Partitioning Option, Oracle Datawarehousing usw...

Downsizing geht mit Abstrichen, ist zumeist aber kein Fehler. Die meisten Leute schwitzen nicht ob des warmen Wetters, sondern da sie sich 'damals' zu warm angezogen haben. Auf der Hardware heute geht mit einfachen Mitteln mehr. Die traditionellen Anforderungen bleiben konstant.

Ich habe mal eine Oracle abgelöst und auf Postgres umgestellt, da die Leute mehr mit SQL arbeiten und der ambitionierten Truppe das entwirrte SQL mehr entgegen kam. Ansonsten muss man zumeist die Liga raufsteigen, wobei ich mich Frage wo die hinter was ein SQL-Server heute schon in der Lage ist zu leisten noch liegen soll.

Zitat:

Zitat von Jasocul (Beitrag 1471464)

Hallo DB-Spezialisten,

...
Aktuell steht noch mySQL bei mir zur Debatte. Für weitere Alternativen bin ich aber offen.

...

Es wäre schön, wenn ich einige Infos aus der Praxis bekommen kann. Wie geschrieben, sind wir für weitere Alternativen immer noch offen. SQL99 muss aber mindestens unterstützt werden.

[haentschman]

Zitat:

bei denen die jetzigen Strukturen des DWH

...und bei einem anderen DBMS ist das anders? Glaube ich nicht...:gruebel: Da kommst du evt. vom Regen in die Traufe...

Zitat:

Es gibt zum Teil komplette Software-Systemwechsel

Welche Software? Eigene, Fremdanbieter?

Zitat:

Das System muss also sowieso im erheblichen Umfang angefasst werden.

Ich denke du solltest bei MSSQL bleiben. Die Anderen haben die gleichen Probleme...oder? :zwinker: Investiere die Zeit in die Umstellung...nur meine Meinung. :wink:

[Jasocul]

@Medium: Danke für die Infos.

@haentschman:
Der Wechsel erfolgt von einer Eigenentwicklung zu einem Fremdanbieter. Der Wechsel ist zwingend, da die alte Software auf Mainframe-Technologie mit Assembler-Programmierung basiert. Entwickler sind in dem Bereich praktisch nicht mehr zu finden und der letzte ASM-Entwickler bei uns geht dieses Jahr in Rente.
Bei so einem Wechsel steht auch das DB-System auf dem Prüfstand. Daher erstmal die technischen Vergleiche. Wenn dort dann keine wesentlichen Unterschiede zu finden sind, werden auch der Preis, Service, Support, etc. zur Beurteilung hinzugezogen.

[Delphi.Narium]

Auch wenn nach Deiner letzten Antwort die Vermutung nahe liegt, dass keine meiner Fragen für Dich von Relevanz ist:

Wieviel Logik liegt denn in der Datenbank?

Prozeduren, Funktionen, Trigger ...

Die "Programmiersprachen" zwischen MSSQL und Oracle sind halt schon recht unterschiedlich.
Wie sehen die Unterschiede zwischen MSSQL und MySQL (oder welcher DB sonst auch immer) aus?

Gibt es "übernehmbare" Logiken aus dem bisherigen System, die beibehalten werden können oder sollen oder müssen.
Ist ggfls. deren Portierungsaufwand berücksichtigt.

SQL ist auch bei SQL99 nicht zwingend = SQL. Da gibt es durchaus Unterschiede zwischen den Datenbanken.

Ist das bisherige System ein absoluter Eigenbau?
Gibt es Fremdsysteme, die irgendwie mit eurem bisherigen System (datenbankseitig) kommunizieren?
Können diese dann ggfls. auch transparent mit 'nem Datenbankwechsel umgehen?
Bzw. gibt es irgendwelche Zwischenschichten, die ggfls. mit angepasst werden müssen?

Wenn ich selbst entscheiden könnte und / oder müsste, und das für ein von Grund auf neue zu erstellendes System, käme bei mir Oracle auf den ersten Platz und zwar aus einem ganz banalen bzw. blöden Grund:

Ich komme mit der SQL-Syntax von Oracle und PL/SQL einfach besser zurecht, als mit den Varianten von MSSQL, MySQL, FireBird ...

Wenn Ihr also vom alten System weg müsst, weil es (bald) niemanden mehr gibt, der sich damit auskennt und ggfls. Weiterentwicklungen und / oder Reparaturen vornehmen kann: Für welches mögliche zukünftige DBMS habt Ihr denn jetzt schon das meiste KnowHow im Hause?
Nicht das Ihr einen zu erwartenden / sicheren KnowHow-Verlust für Euer jetztiges System (unwissentlich) für mehr oder weniger nahe Zukunft auf Euer neues System übertragt.

Also: Nicht nur die technischen Unterschiede der zukunftigen und möglichen DBMS vergleichen, sondern auch deren Zukunftssicherheit.

Gibt's den Herstellen des gewählten DBMS in 5 Jahren, in 10 Jahren, bei Deiner Rente, bei der Rente der jetzt neueingestellten Entwickler, ... auch noch und ist auf dem Markt jetzt und voraussichtlich in näherer und in fernerer Zukunft ausreichendes KnowHow verfügbar?

[Jasocul]

@Delphi.Narium:
Danke für dein Brain-Storming. Keine Gedanke davon ist irrelevant und muss berücksichtigt werden.

Zitat:

Zitat von Delphi.Narium (Beitrag 1471506)

Auch wenn nach Deiner letzten Antwort die Vermutung nahe liegt, dass keine meiner Fragen für Dich von Relevanz ist:
Wieviel Logik liegt denn in der Datenbank?

Schon so einiges, aber bei weitem nicht genug. Es soll zukünftig soviel wie möglich durch die DB erledigt werden.

Zitat:

Zitat von Delphi.Narium (Beitrag 1471506)

Die "Programmiersprachen" zwischen MSSQL und Oracle sind halt schon recht unterschiedlich.
Wie sehen die Unterschiede zwischen MSSQL und MySQL (oder welcher DB sonst auch immer) aus?

Ich komme ursprünglich von Oracle und musste mich an MS-SQL gewöhnen, kenne also beides.

Zitat:

Zitat von Delphi.Narium (Beitrag 1471506)

Gibt es "übernehmbare" Logiken aus dem bisherigen System, die beibehalten werden können oder sollen oder müssen.
Ist ggfls. deren Portierungsaufwand berücksichtigt.

Da die gesamte DB-Struktur aufgebrochen wird, gibt es kaum Logiken, die übernommen werden können. Das ist auch berücksichtigt.

Zitat:

Zitat von Delphi.Narium (Beitrag 1471506)

SQL ist auch bei SQL99 nicht zwingend = SQL. Da gibt es durchaus Unterschiede zwischen den Datenbanken.

Das ist bekannt. Es gibt einige Features in SQL99 die ich zukünftig endlich nutzen können möchte. Wie das dann im jeweiligen Dialekt ausgeprägt ist, ist reine Übungssache.

Zitat:

Zitat von Delphi.Narium (Beitrag 1471506)

Ist das bisherige System ein absoluter Eigenbau?
Gibt es Fremdsysteme, die irgendwie mit eurem bisherigen System (datenbankseitig) kommunizieren?
Können diese dann ggfls. auch transparent mit 'nem Datenbankwechsel umgehen?
Bzw. gibt es irgendwelche Zwischenschichten, die ggfls. mit angepasst werden müssen?

Ja.
Ja.
Zum größten Teil, da die Schnittstellen Eingenentwicklungen sind.
Mit Sicherheit.

Zitat:

Zitat von Delphi.Narium (Beitrag 1471506)

Ich komme mit der SQL-Syntax von Oracle und PL/SQL einfach besser zurecht, als mit den Varianten von MSSQL, MySQL, FireBird ...

Da bin ich ganz bei dir, möchte aber im Moment noch ergebnisoffen bleiben.

Zitat:

Zitat von Delphi.Narium (Beitrag 1471506)

Für welches mögliche zukünftige DBMS habt Ihr denn jetzt schon das meiste KnowHow im Hause?
Nicht das Ihr einen zu erwartenden / sicheren KnowHow-Verlust für Euer jetztiges System (unwissentlich) für mehr oder weniger nahe Zukunft auf Euer neues System übertragt.

Aktuell MS-SQL. Sollte sich das DB-Sytem ändern, bekommen wir entsprechende Schulungen. Kostet auch wieder Zeit und Training, aber das ist den Entscheidern bewusst.

Zitat:

Zitat von Delphi.Narium (Beitrag 1471506)

Also: Nicht nur die technischen Unterschiede der zukunftigen und möglichen DBMS vergleichen, sondern auch deren Zukunftssicherheit.

Ein grundsätzliches Problem, dass immer ein Restrisiko birgt. Open-Source wird bei entsprechender Verbreitung kaum sterben. Große Unternehmen können Pleite gehen oder verkauft werden. Aber Delphi lebt ja auch noch trotz diverser Verkäufe :wink:

[jobo]

Meine persönliche Einschätzung zu

Oracle:
++Programmierbarkeit
+Feature Reichtum
+Support
-- Preis
- Lizenzpolitik
MSSQL:
+ Tools (vielleicht)
+ Programmierbarkeit
- Preis
- Ressourcen „Looser“ (gefühlt, wegen Sperrverhalten > lock escalation)
mySQL/Maria*:
- Features
+ Speed (vielleicht/ Glaubensfrage)
+ Preis (mysql)
++ Preis , Lizenz (maria)
- Robustheit/Zuverlässigkeit/Limits
- Programmierbarkeit
- Produktpflege
Postgres
+ Feature Reichtum
++ Programmierbarkeit
+ Indizierbarkeit
+ Flexibilität / Extensions
++ Preis
++ Lizenz
++ Produktpflege und Erweiterung
+ SQL ANSI Standard Konformität
(+ Oracle Kompatibilität)


Oracle hat Standards gesetzt, MSSQL jagt dem (immernoch) nach. In der OS Ecke braucht man m.E. nicht über mySQL und Ableger nachzudenken, besonders nicht, wenn es um Programmierbarkeit geht. Dort tut sich Postgres sehr positiv hervor und vielleicht kann man über Firebird nachdenken (das würde ich jedenfalls eher nehmen als mySQL).

* Ich kenne nur die vielen Probleme der Entwickler mit mySQL und nutze weder noch in der Praxis. Leider ist ja Maria angeblich kompatibel zu mySQL, keine Ahnung, ob das auch für Bugs und Limitierungen gilt.

[Jasocul]

Danke Jo.
Ich werde mir dann auch mal Postgres genauer ansehen.

[t2000]

Ich habe es jetzt auch nur überflogen.
Aber wir sind vor lange Zeit von Oracle auf MS SQL umgestiegen, weil es subjektiv einfacher ist.
JETZT steigen wir von MS SQL auf PostgreSQL um, weil Microsoft gravierende Fehler seit 8 Jahren nicht behebt.

My SQL ist nicht geeignet für solche Datenmengen (meine Ansicht).

Also, von auch jetzt nur der Tipp: PostgreSQL ansehen!

[jobo]

:thumb:

"MSSQL ist subjektiv einfacher"
Vielleicht ist damit das Tooling gemeint. MS kann gut IDE und Luxus und Automatik, aber das war's dann.
RDBMS sind im Kern zu einem hohen Anteil einfach SQL (nach ANSI Standard xy), beim einen Hersteller mehr, beim anderen weniger, aber 90 oder mehr Prozent ist identisch. Danach wird es spannend. Ob ich mein Datenmodell nun mit Notepad eintippe, mit einem Luxustool male oder per Excel ausspucke, am Ende muss die DB solide und vielfältige Funktion daraus abbilden.
"subjektiv einfacher" kann natürlich auch die Adminschiene meinen. Alles bunt und klickbar bei MS SQL. Leidet aber unter dem Grundproblem, das eine bunte UI nicht skaliert. Bei einer DB egal, bei 2 auch, bei 20 nicht mehr. Oracle und die schiere Fülle an Möglichkeiten (und Plattformen, Erweiterungen, ..) kommt auch da mit einem gewissen Preis daher, Administration wird komplizierter einerseits, andererseits wird auch ständig harmonisiert und flexibilisiert.

Postgres ist in meinen Augen top Leistung, die man geschenkt bekommt (funktional an vielen Stellen weiter als MSSQL). Bei Bedarf mit Support durch professionelle Firmen.

werbung off
;)

[Delphi.Narium]

Oracle: Gute Oberfläche (mit mehr Möglichkeiten, als dass ich je sie hätte vollständig nutzen können)? Toad

Als Entwickler hab' ich nie mehr benötigt.

Ging's über das dort Mögliche hinaus, kamen die Datenbankadministratoren zum Zuge (was ziemlich selten der Fall war ;-))

[TigerLilly]

Zusätzlich zu den technischen Inputs: Welches Know-How für ein bestimmtes System ist denn bereits verfügbar? Ein neues DB-System anzuschaffen, für das inhouse kein KnowHow gibt, ist eine teure Sache. Wenn Ihr schon MS-SQL Erfahurng habt, bleibt bei MS-SQL. Wenn Ihr Oracle-Erfahurng habt, bleibt bei Oracle.

[jobo]

Vorhandene Skills werden oft als Argument bei solchen Fragen angeführt. Wenn Unternehmen in den USA sich gezwungen sehen, auf "exotische" Programmiersprachen umzustellen, weil Großunternehmen den "Entwicklermarkt" lehr saugen, dann sind das die extremsten Blüten dieses Themas.

Aber bei SQL? Egal welches System
SQL ist SQL. Ein korreltiertes Update wird hier ein wenig anders als da formuliert, ein Upsert auch, aber der größte Teil ist identisch. Die Theorie zur Modellierung ist sowieso identisch. Man stellt in System A nicht alles auf den Kopf, was in System B gut und richtig war.
Irgendwann kommen natürlich die Feinheiten, das kann die Frage Sequence oder Autoinc betreffen, Lockverhalten und geht natürlich bis zur Programmierung (sofern die DB das bietet). Und klar, da reicht es nicht, wenn ich zwischen jede Zeile PL/SQL Code ein GO schreibe, damit ich TSQL habe. Trotzdem geht es auch in der DB Programmierung immer wieder um die gleichen Techniken.

Am Ende muss es natürlich jemand geben, der eine DB administriert. Das fordert m.E. am ehesten spezifische Skills. Aber ein Unternehmen mit 10 Entwicklern hat nicht gleichzeitig auch 10 DB Admins oder?

Den Datenbankanbieter zu wechseln, ist für den Entwickler m.E. kein Paradigmenwechsel, wie es vielleicht der Umstieg von einer Programmiersprache zur anderen sein kann. Im Gegenteil, viele IDE treten an, mit beliebigen DB zu arbeiten zu können, siehe Delphi.

[Bernhard Geyer]

Ist das Datawarehouse nur intern eine Installation (also zwei wenn man das Testsystem mit betrachtet) oder ist das auch das als SW-Lösung verkauft wird.
Wenn es verkauft wird und bei mehreren Kunden im Einsatz wäre, dann solltet ihr einen DB-Neutralen Ansatz fahren.

Wenn es nur intern ist, dann würde ich (aufgrund meiner Erfahrung sagen).

Oracle nur wenn man einen verdammt fähigen Oracle-Admin "zur Hand" hat. Wir hatten bei unseren Kunden schon öfter den Fall das hier teilweise absolute Unfähiges Leute als Admin eingesetzt sind, deren einzige Antwort ist das dies ja wohl ein Fehler der eingesetzt SW sein muss.

MySQL ist auf jeden Fall einfach zu Administrieren, aber auch hier sollte ein Admin entsprechend Ausgebildet sein. Es gibt da so einige Fallstricke bei MySQL die man nicht so leicht findet. Unsere DBs die wir auf MySQL laufen haben sind aber auch nicht so an Anspruchsvoll. Über 2stellige GB-Bereich kenn ich keine

MS SQL ist mein bevorzugtes DBMS. Hat zwar auch einge Macken, aber verglichen mit den beiden anderen verursacht dies (im Kundenumfeld) die wenigsten Probleme.
Kann m.E. Problemlos mit Oracle was Performance und DB-Größe betrifft mithalten. Unsere Größte DB ist knapp unter 2-stelligen TB angekommen und läuft mit auf SSDs + relativ wenige RAM (ich glaube 32) performant (Jedenfalls sind die Flaschenhälse eher die Anwendung als das DBMS)