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

[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]

"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)