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

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