Neues Datenbank-Backend für meine Anwedung - Welches?

[berens]

Hallo zusammen,
wie aus meinen vorherigen Beiträgen zu sehen ist, verwendet meine Software (CMS für Infobildschirme) als Datenbank die guten alten .mdb-Dateien: das Datenbankformat von Access 2003.

Dieses Format wird zwar viel belächet (auch in Anbetracht des abgelaufenen Supports und des Alters), aber bei sogut wie allen Kunden kam es gut an, dass wir unsere "Netzwerk"-Software direkt ohne Server und Portfreigaben in der Firewall in Betrieb nehmen können, einfach nur durch den gemeinsamen Zugriff auf die Datenbank über ein Netzlaufwerk. Bei vielen Kunden wäre die Installation eines *SQL-Servers für nur zwei Geräte [zu] viel Aufwand, bei anderen -großen- Kunden müssten erst intern Anträge geschrieben werden etcetc (Projektverzögerungen / -kosten), und mit dieser rein dateibasieren Lösung können eigentlich Alle ganz gut leben. Auch werden -im Vergleich zu den neueren Access-Datenbanken (.accdb) und MySqL keine Drittanbieterprogramme benötigt (Access Runtime blabla, MySQL ODBC Treiber (für TAdoConnection!), ...) Ein entscheidender Vorteil (war) auch, dass man die Datenbank mit einem USB-Stick auf einen Infobildschirm aufspielen kann, der über keinerlei Netzwerkanbindung verfügt.

Jedoch leben wir nun in 2020, und aktuelle Probleme zwingen uns, uns schon vor einer neuen Hauptversion mit der Migration auf ein neues Datenbanksystem zu beschäftigen.

Bei Access-Datenbanken treten gelegentlich folgende Probleme auf:

1) Datenbank ist nach dem Schreiben in inkonsitentem Zustand und kann nicht über MDAC/OLEDB/JET repariert werden, nur direkt über Access. Beim Kunden steht "alles still" weil bis zum Reparieren kein Infobildschirm mehr auf die Datenbank zugreifen kann.

2) Datenbank wächst rasant an (dazu gibt es auch Themen hier im Forum): Die Transaktionsprotokolle sorgen dafür, dass die Datenbank innerhalb eines Tages um ~60 MB anwächst, und das, obwohl in der konkreten Situation "nur" alle 15 Minuten ca. 100 Einträge gelöscht und neu geschrieben werden. Nach einigen Tagen erreicht Diese theoretisch 2GB und kollabiert dann (bekanntes Problem). Datenbank "reparieren und komprimieren" in Access hilft - bis zum nächsten Tag. Zudem kann die Datenbank nicht repariert und komprimiert werden, da/sobald ein weiteres Gerät über Netzwerk darauf zugreift, was aber eigentlich immer der Fall ist, da die Infobildschirm eigentlich den ganzen Tag laufen.

3) Aktuelles Problem mit den Mai 2020 Windows Updates, wobei auch auf Einzelplatzinstallationen Windows die Datenbank beim Schreiben einer einzigen Zeile komplett "zerschießt", weil irgendwass mit dem generellen Schreibzugriff von Anwendungen auf die Festplatte geändert wurde.

4) Problem, wenn die Netzlaufwerks-Freigabe (SMB) mit der Datenbank auf einem Windows 2008/2016 Server liegt: Es können nicht mehr als zwei Leute gleichzeitig die Anwendung geöffnet haben. Unbekannte Ursache / Lösung.


Ich höre schon eure Einwände: Access-Datenbank mit Multiuser gleichzeitig? Die AdoConnection den ganzen Tag geöffnet? Kunden arbeiten über Netzlaufwerk (ggf. sogar über VPN!) mit einer .mdb-Datei? "Ohje-Ohje". Ja, geht eindeutig professioneller, ist aber -ganz ehrlich-: Pflegeleicht und hat bis dato immer gut geklappt - Ausnahmen siehe Oben.

Hier im Forum wird ja im "pinned" Thema mehrere Datenbanksysteme für Delphi vorgestellt. Jetzt stehen natürlich auf den Webseiten und den Produktdatenblättern viele tolle Sachen drin. Ich brauche 4-5 Tabellen. In der Größten stehen max. 300 Zeilen mit ~10 String-Spalten, die meisten anderen Tabellen sind i.d.R. leer - das ist also wohl kein Kriterium für die Suche. Was mich interessiert ist der Erfahrungswert, den Ihr mit einem bestimmten Datenbanksystem habt, und wie sich das auf meine u.g. Punkte anwenden lässt.

Aktuell arbeite ich mit TAdoConnection und eigentlich nur TAdoQuery, keine Stored Procedures oder Ähnliches. Das Programm ist -sagen wir- "historisch gewachsen" und ich müsste nun natürlich an vielen Stellen Alles, was mit Datenbanken zu tun hat, auf eine neue Komponente/Abfragesprache anpassen. Sei es drum, muss halt.

Generell spiele ich ja mit dem Gedanken, einen Microsoft SQL Express Server zu verwenden. Die Ansteuerung im Programm wäre fast unverändert, die Migration bei den Kunden "machbar". Leider bin ich da ein wenig ein "gebranntes Kind" weil ich im Leben schon viele, viele Probleme mit SQL-Express hatte, z.B. wenn diese als Datenbanken für OnPremise-Virenscanner (Symantec, Sophos Antivirus) zu Einsatz kamen: Ein riesen Trara bis das Alles installiert ist, dann gibt es schon eine Instanz "SQL-Express", dann hat die neue Instanz andere Portnummern etc., Backup und Wiederherstellung -ohne weitergehende Beschäftigung damit- scheinbar auch größere Aktion. Zunächst Alles nur Vorurteile von mir für Versionen von vor > 10 Jahren, vielleicht kann man ja jemand dies bzgl. eines Besseren belehren?
Auch macht mir Sorgen, ob/wie einfach ich dann auch Daten mal von einem PC auf einen anderen Migrieren kann (eigentlich ja wieder nur das Backup/Restore "Problem" - wahrscheinlich heutzutage zwei Klicks und alles ist gut), bzw. falls der Kunde eine merkwürdige Situation in unserem CMS erreicht hat, wäre es auch gut, wenn er uns "mal schnell" die Datenbank zusenden kann (Aktuell: .mdb als .zip in den E-Mail Anhang, mit MS SQL Express denke ich mal ein wenig aufwändiger, aber machbar).

Generell bin ich auch offen für anderen Datenbanksysteme. Ich bin nach wie vor eigentlich tatsächlich ein Fan von dateibasierten Datenbanken, aber bei jedem Datenbankanbieter habe ich wieder gewisse Bedenken, und ich wäre euch sehr dankbar, wenn ihr sie ausräumen würdet:

1) Folgekosten: Hier muss ich den "Pinned" Thread im Detail durchlesen, speziell wegen Lizenzen etc. Mein zukünfiges Datenbanksystem sollte idealerweise mit dem Kauf von Delphi von für den Einsatz bei allen Kunden lizenziert sein ("Royality Free"?), oder generell so kostenlos sein, dass ich es mit meinem Installer ausliefern darf, ohne Verklagt zu werden, ohne meinen Quellcode komplett offenlegen zu müssen oder einen Betrag von X € pro Installation bezahlen zu müssen. Dito für die Delphikomponenten, die ich dann in meiner Anwendung einsetze. Einmaliger Kauf bis in den 4stelligen Bereich wäre in Ordnung.

2) Kompatibilität: Meine Software ist (und bleibt?) ein reines Windows Programm. Das Datenbanksystem muss also auf Windows laufen.

3) Stabilität: Siehe Probleme oben. Die Datenbank darf nicht so dermaßen anwachsen, dass ich Sie /nur/ im Exklusiv-Zugriff komprimieren kann. Auch sollte sie nie in einen "inkonsistenten Zustand" verfallen, den die Vermittlerkomponente von Delphi (Datenbankschicht) nicht von alleine -automatisch- reparieren kann. Könnte mir vorstellen, dass das für rein dateibasierte Datenbanken schon technisch nicht möglich ist. Reine XML-Dateien wäre für die paar wenigen Daten schon ne feine Sache, aber dort habe ich auch wieder "Angst", dass schon ein falsch interpretiertes "<" ausreicht, und die komplette Datenbank zu zerschießen.

4) "Threadsicherheit": Wenn ich in einem Thread eine Datenbankverbindung herstelle und etwas lese/schreibe, muss sich das in keiner Weise in Echtzeit auf Abfragen in anderen Threads und den Hauptsthread auswirken. Wenn ich im Thread was schreibe, erwarte ich eine ordnungsgemäß ge"post"ete Zeile, deren AutoIncrement-Wert für "ID" korrekt ist, und nach dem Schreibvorgang die Datenbank garantiert immernoch in einem konsistenten Zustand ist. Es sollen/dürfen keine Exceptions auftreten, wenn zwei Threads mit der selben Tabelle arbeiten (jeweils nur abgeschlossene Operationen, immer nur eine Zeile wird verändert, keine Änderungen an der Tabellenstruktur im Thread).

4) Administrator-Freundlichkeit: Interessenten und Administratoren möchten unsere Software natürlich auch mal auf dem eigenen PC schnell in Betrieb nehmen. Bei MS SQL Express stelle ich mich das schon aufwändiger -dennoch machbar- vor. Dennoch sollte der Server schnell installiert sein, ohne tiefergehende Konfiguration. In unserem Programm darf dann max. IP-Adresse/Port, User, Passwort angegeben werden; die Software legt dann Tabelle und Daten an. Sollte jede Software können? Brauchen manche MEHR Konfiguration?

5) Keine erzwungenen Callbacks: Mit Delphi 2010 asynchron zu der eigentlichen Prozedur selbsgebastelt JSON-Antworten auszuwerten, ist ein Graus. Ich sollte schon alles in einem rutsch schreiben können, z.B. eine Zeile schreiben, eindeutige ID auslesen, in der anderen Tabelle verweis auf diese ID machen etc. Sollte Standard sein, kann aber auch sein, dass das halt wie in diesem Beispiel nicht überall Standard ist? (Mit neuem Delphi dürfte auch JSON einfacher sein...)

6) Multi-User: Hier kommt nun ein Knackpunkt: Das Datenbanksystem sollte problemlos mit 15 Clients zurecht kommen, die exemplarisch 1x die Minute auf eine Abfrage 20 Zeilen zurückgeliefert bekommen. Idealerweise sollte das auch mit bis zu allerhöchstens 50 Clients gehen, die durchschnittliche Installation kommt auf 1-2 Clients. Auch sollte es es kein Weltuntergang sein, wenn ein (1) Client im Netzwerk über eine ~2 MBit VPN Leitung angebunden ist und etwas abfragen will (wie gesagt: ~20 Zeilen als Ergebnis der Abfrage).

7) Keine "Exoten". Das neue Datenbanksystem sollte "generell bekannt sein" und die Verwendbarkeit auch in 10 Jahren sicher sein (Ansteuerbarkeit mit Delphi --> Komponenten; Backend/Server installierbar auf dem dann jeweils aktuellen Windows OS).


Mir ist bewusst, dass Ihr mir mit Antworten zu dem Thema viele, viele Stunden Recherchearbeit zu den einzelnen Anbietern abnehmt, was eigentlich unverschämt von mir ist auszunutzen. Aber viele Sachen -gerade bei der Programmierung- stecken im Detail, und bevor ich jetzt "laut Prospekt" das scheinbar am Besten für mich passende heraussuche, und nachher -wenn die Probleme da es- es heißt "Hättest du mal vorher gefragt" - frage ich nun halt vorher. Vielleicht wisst ihr ja zu den einzelnen Punkten K.O. Kriterien, wo Datenbanksystem X schon generell rausfliegt.

Vielen Dank im Voraus!