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

[Jasocul]

Zitat von 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; ...

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

Zitat von philipp.hofmann:

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? Never touch a running system.

[Jasocul]

Zitat von haentschman:

Zitat:

bei uns gibt es Planungen, das Datawarehouse komplett neu aufzubauen

...die Frage ist...wieso? Never touch a running system.

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.

[Medium]

Zitat von Jasocul:

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.

[haentschman]

Zitat:

bei denen die jetzigen Strukturen des DWH

...und bei einem anderen DBMS ist das anders? Glaube ich nicht... 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? Investiere die Zeit in die Umstellung...nur meine Meinung.

[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 von 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?

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

Zitat von Delphi.Narium:

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 von Delphi.Narium:

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 von Delphi.Narium:

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 von Delphi.Narium:

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 von Delphi.Narium:

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 von Delphi.Narium:

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 von Delphi.Narium:

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

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