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

[Neumann]

Also ich würde Firebird nehmen. Ist kostenlos, einfach zu installieren, wartungsarm und auch der Zugriff über Netzwerk erfordert nur eine Freigabe in der Firewall. Mehrere Zugriffe sind auch kein Problem; natürlich können nicht zwei Clients gleichzeitig eine Datensatz bearbeiten aber das geht wohl in keiner Datenbank.

Weiter Infos findet man z.B. bei IBExpert.

[Blackpit]

Zitat von Neumann:

Also ich würde Firebird nehmen. ...

Schließe mich an, erfodert ein wenig Einarbeitung.
Bei der genannten Konstellation würde aber der Umzug auf einen MS-SQL(Express würde vmtl. reichen) möglicherweise weniger Aufwand machen.

Gruß BP

[mensch72]

Mein Vorschlag: Access Datenbank mit dem "SingleFile.MDB" einfach beibehalten!

Da wo das MDB File physisch liegt, arbeitet die Applikation mit aktiviertem "TMS-RemoteDB-Server".
Auf allen anderen Clients arbeitet die Applikation via TMS-RemoteDB-Connection (RemoteDatasets/Querys... logisch & funktional im Prinzip 1:1 austauschbar mit ADOconnection, ADOdataset, ADOquery).

Wirklich langsamen ext. Clients kann man via Batch basierter Autoreplikation ("TMS-Echo") eine quasi lokale DB zum arbeiten bieten, und diese die Replikation läuft via Push/Pull Commits oder extra SyncRequest bei Bedarf.

Speziell wenn es bisher durchaus möglich&üblich mal fix das komplette DB-File gepackt hin&her zu schicken oder im Support so selbst schnell zwischen verschiedenen Mandanten-MDB-Files wechseln zu können... bietet sich das TMS Zeug auch schon ohne Nutzung von deren ORM durchaus an.
(~400€ will TMS dafür als "TMS Business Subscription" fürs erste Jahr haben, ab 2. Jahr dann jeweils 30% für die Update&Support-Verlängerung. Keine weiteren sonstigen Lizenz oder Installationskosten.)


https://tmssoftware.com/site/remotedb.asp
https://tmssoftware.com/site/tmsecho.asp

[mytbo]

Ich traue mich mal, das Open Source Framework mORMot ins Spiel zu bringen. Eine ausführliche Hilfe findest du hier:
https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html

Weitere Informationen findest du hier:
https://synopse.info/fossil/wiki?name=Downloads
https://synopse.info/forum

mORMot musst du nicht installierten. Es reicht aus, die entsprechenden Bibliothekspfade einzufügen.

Deine Anforderungen sind so gering, dass du alles mit dem integrierte ORM und embedded SQLite3 locker erledigen kannst. Um die Einbindung der SQLite Engine musst du dich nicht kümmern, wird automatisch in deine EXE mit einkompiliert. Du kannst dann gleich auf eine RESTful/SOA architecture umsteigen (klingt viel schlimmer, als es in Wirklichkeit ist). Deine eigentliche Arbeit ist mit mORMot schnell erledigt, das Problem dürfte sein, dich in mORMot einzuarbeiten. Es steht eine ausführliche Hilfe, viele Beispiele und ein freundliches Forum zur Verfügung.

Bis bald...
Thomas

[berens]

Vielen Dank zunächst für die bisherigen Antworten.

Firebird klingt ja generell erstmal interessant, und die gemeinsame Geschichte mit Interbase und Delphi ist generell ein gutes Zeichen für die Integrierbarkeit in und Migriegbarkeit für meine Anwendung. Da beide ja den selben Ursprung haben dachte ich eben flux, dass ich dann lieber die "Professionelle" Lösung von Interbase nehme, die bei Delphi mit dabei ist (je nach Version?), aber dann habe ich erst gesehen, was für Kosten da schon schnell für eine einfache Installation beim Kunden entstehen können, da muss ja "alles" pro-Kunde dazugekauft werden. Somit denke ich ist InterBase raus, die Auswahl wird kleiner und übersichtlicher.

Firebird: Einfache Installation, direkte Verbindung über TCP/IP, Datenbanken als einfache (leicht sicher und tauschbare) Datei auf der Festplatte. Brauche dann entweder andere Komponenten in Delphi als die TAdoConnection, oder den ODBC-Treiber - den müsste ich dann mit meinem Installer mitliefern (sollte Lizenztechnisch nix kosten; aber was sagen die Admins zu dem zusätzlichen Programm auf jedem PC). "Sorge" macht mir in diesem Fall -leider!- das "OpenSource", weil gerade bei den großen Kunden manche Administratoren Nachweise für Wartungsverträge für /alle/ Softwaretitel im Haus liefern müssen. Gibt's hierfür bestimmt auch zu kaufen, wäre aber so ein "Naja-Punkt". Trotzdem erstmal ein großes Plus. Liegen hier Erfahrungswerte vor, "wie oft" schon mal eine Datenbank korrupt/inkonsisten geworden ist (nicht durch Hardwaredefekt, nur im "Normalbetrieb" von jetzt auf eben)? Wie einfach oder "möglich" ist eine Reparatur? Danke @Neumann

Die Idee von @Mensch72 finde ich super mitgedacht; von TMS setzte ich schon erfolgreich andere (nicht-Datenbank) Komponenten ein. K.O. Argument ist hier leider dann doch wieder die Access-Datenbank, die sich pro Tag um ~60 MB aufbläht, auch wenn nur lokal gearbeitet wird. Natürlich könnte man auf dem "Server" dann besser die DB mal kurz schließen und im Exklusivmodus komprimieren/reparieren aber ... wenn ich jetzt schon die Software grundlegend ändere, dann versuche ich wirklich die o.g. Punkte abzudecken (gerade auch das tagesaktuelle Patchday 05/2020 Problem wäre damit nicht gelöst, aber egal: bis -hoffentlich- Microsofts Update für das Update kommt, habe ich eh mein Programm nicht auf ein anderes System umgestellt. Ich denke aber, dass andere Datenbanken (SQL, ...) wohl von diesem Patchdayproblem nicht (so) betroffen sind, wie mdb-Dateien ...). Von der Idee her trotzdem sehr gut.

Die Idee von @mytbo ist auch nicht verkehrt. REST und SOAP hab ich ja jetzt auch schon öfters gehört, speziell in Verbindung mit meinem Delphi 2010 (neue Version kaufe ich mir noch in diesem Jahr irgendwann ...) stellen sich mit aber beim Gedanken an REST APIs mit selbstgebastelten Indy-Threads und zusammengestückelten JSON-Interpretern alle Nackenhaare. Wenn du das empfiehlst gehe ich davon aus, dass es für Delphi gute Komponenten gibt, die sich um das Alles kümmern, und ich mich wirklich nur mit dem eigentlichen Datenbank-Kram beschäfigen muss. Da wir jetzt leider zwischen zwei Hauptversionen diese Datenbankumstellung ungewollt "übers Knie brechen müssen" -zwar nicht als Schnellschuss, aber dennoch "als Feature mit höchster Priorität", hätte ich glaube ich ziemlich Bauchweh damit, schon alleine ein Backend einzusetzen, das ich nicht auf Anhieb verstehe. Firebird und *SQL ist klar: Server installieren, Datenbank anlegen, mein überarbeiteter Client verbindet sich drauf - fertig. Bei Synopse -und das kann ich jetzt nach kurzem Überfliegen der Dokumentation nur vermuten- schein ja (weil "Framework") /mehr/ dabei zu sein, (HTTP Client und Server, JS Enging, ein MongoDB Server, ...) als das was ich jetzt als klassischen Datenbankserver abstempeln würde. Sicherlich ist dieses Framework für die vorgesehenen Verwendungszwecke genial, aber ich stehe gerade davor wie k.a. ... ein Automechaniker der einen zweiwöchigen Lehrgang für die Reparatur von einer neuen Generation Autos haben möchte, und er ein Angebot für einen Lehrgang bekommt, der alle Themen für Autos, Züge, Luftfahr und Schiffe abdeckt. Dauer des Lehrgangs nicht absehbar; der Nutzen für die erweiterten Fähigkeiten verpufft, weil Arbeitgeber=Autowerkstatt. Long story short: Ich glaube, dieses Framework würde mich gnadenlos überfordern. Bei einer komplett neuen, sauber konzeptionierten Software mit ausreichend Zeitpuffer für die Einarbeitung könnte ich mir das durchaus vorstellen, hier in diesem konkreten Fall aber glaube ich würde zu viel Energie verpuffen, weil ich mich wahrscheinlich mit trivialen Problemen "von Null" beschäftigen müsste, die ich nun mit ADO nach vielen Jahren endlich halbwegs gemeistert habe. Zudem kommt: Ich muss ja ein wenig Support beim Kunden leisten können, falls mit der DB-Server Software was klemmt, und ich glaube da wäre ich bei dem Framework echt raus. Vielleicht finde ich mal auf Youtube ein kleines Tutorial zu diesem Server und 'ner beispielhaften Delphiimplementierung, aber ich denke ihr wisst was ich meine wenn das Bauchgefühl sagt "das passt nicht", auch wenn ich es fachlich nicht ordentlich begründen kann.

> zwischen verschiedenen Mandanten-MDB-Files wechseln zu können
In der Tat ist es so, dass wir projektbezogen auch [die Inhalte der] Datenbanken für Kunden vorbereiten und Ihnen dann die Daten schicken. Bis dato konnte das auch eine Sekretärin durch das austauschen der .mdb erledigen. Mit *SQL stelle ich mir das schwerer vor, da man einerseits auf die Serverkonsole Zugriff haben muss (nagut, nofalls über die MMC als externe Konsole, bzw. Remotedesktop mit Admin-Daten). In jedem Fall muss der Admin wieder bemüht werden.

Bei diesen ganzen Überlegungen hat @Blackpit natürlich auch recht: Die (ungeplante) Migration meiner Software wäre wahrscheinlich auf MS SQL Express am einfachsten umzusetzen. Sofern ich nicht falsch liege, hätten meine "großen" Kunden dann ja auch die Möglichkeit, die Datenbank auf "ihrem" eigenen richtigen SQL-Server zu hosten, so dass eine zusätzliche Instanz von SQL Express nicht notwendig ist. Zudem haben viele Administratoren zumindest grundlegende Erfahrungen mit Microsoft SQL (Express), so dass diese bei Datenbankproblemen besser agieren können, als jetzt mit dem mORMot Framework wo zwei Ahnungslose dann miteinander telefonieren würden. Ja, natürlich! Vor der Implementierung muss auch ich mich mit der neuen Serversoftware beschäftigen und mich "nicht nur" grundlegend damit auskennen, aber ich wisst was ich meine: Grundlegende SQL-Server Kenntnisse sind bei mir vorhanden, bei dem Framework würde ich bei "weniger als Null" anfangen. Auch der Bekanntheitsgrad und die Updates von Microsoft sollten eigentlich viele Bedenken zerstreuen, "der Admin weiß, was bei Ihm installiert wird", wenn ich's mal so sagen darf.

Mir ist bewusst dass ich mich gerade anhöre wie "Will er eigentlich uns überzeugen, oder sich selbst? Scheint als hätte er schon eine feste Meinung..." aber mehr oder weniger ist es das ja auch. Letztendlich will ich von Fachleuten aus dem Gebiet hören: "Ja, für dein Vorhaben ist das genau richtig.". Es muss nicht die beste Lösung sein die technisch möglich ist - es muss nur mind. genauso gut funktionieren wie vorher und ich darf jetzt nicht die nächsten Monate und Jahre mit dem neu-lernen anderer Datenbankgebilde verbringen...
Firebird wäre *echt* cool, aber für das gute Gelingen unseren Projekten spielt auch immer das Bauchgefühl vom Administrator des Kunden eine wichtige Rolle. Wenn ich auf dem "großen Server" eines neuen Kunden ein Programm/Dienst als Administrator installieren will, und der Admin fragt "Watt ist Firebört, und was macht das auf meinem Server?" wirkt das anders als wenn ich Frage: Haben Sie einen eigene SQL-Server, oder soll ich den auf dem Infobildschirm mit drauf machen (gnaaa, braucht dann feste IP oder Hostnamen etc....)? Klar, Firebird kann ich auch auf "meinen" Infobildschirm-PC drauf machen, aber es beruhigt -denke ich mal- den Admin sehr, wenn er schon die Drittanbieterprogramme /kennt/ die evtl. da einfach so mitinstalliert werden.


Wenn wir jetzt mal den direkten Vergleich Firebird <--> MS SQL Express angehen... Was muss ich beachten?

1) Können auf Beide -beispielhaft!- bis zu 50 Clients gleichzeitig zugreifen? Lizenztechnisch okay? Wird wohl nie passieren, ich will mich aber nicht vorab künstlich beschränken. (Kann des MS-SQL Server das? Soweit ich weiß gibt's dann dafür die CALs im 25er(?) Pack.)

2) Frage nach der Stabilität/Inkonsitenzen speziell Firebird unter den o.g. Aspekten, bzw. störungsanfälligkeit von MS SQL (Dienst/Agent startet nicht, Port nicht erreichbar, Datenbankdatei-Probleme, ...)

3) Wie einfach ist das Deployment des Server über meinen Installer? Rechtliche Probleme / Folgekosten / Lizenzierung bei Firebird <--> MS SQL Express?

Freue mich auf Antworten, danke soweit!

[Andreas13]

Hallo,
schau doch mal hier rein: http://www.componentace.com/bde_repl...e_database.htm
Vielleicht ist es was für Dich: Absolute Database als embedded Database. Relativ einfach zu benutzen, alles wird – ähnlich wie bei Access – in einer einzigen Datei gespeichert.
Gruß, Andreas

[scrat1979]

Zitat von Andreas13:

Hallo,
schau doch mal hier rein: http://www.componentace.com/bde_repl...e_database.htm
Vielleicht ist es was für Dich: Absolute Database als embedded Database. Relativ einfach zu benutzen, alles wird – ähnlich wie bei Access – in einer einzigen Datei gespeichert.
Gruß, Andreas

Sehr gut, verwende ich auch. Allerdings wird von ComponentAce das Ablegen der Datei auf einem Netzwerkordner nicht empfohlen. Ich verwende es für einen Terminplaner mit ca. 100 Einträgen pro Tag. Das einlesen über das Netzwerk von 90 Tagen geht ratz fatz. Allerdings habe ich mir einen eigenen Server geschrieben der sich um die Datenbank kümmert, der Server kommuniziert über ein eigenes „Protokoll“ mit den Clients. Das heißt die Clients greifen nicht direkt auf die Datenbank zu. Möchte auch mittelfristig auf FireBird wechseln (auch einfach aus Interesse). Da habe ich momentan allerdings weder Zeit noch Lust. Verwende es nur „privat“ bzw. im eigenen Geschäft.

Aber prinzipiell eine tolle Datenbank die ich - vor allem für lokale Projekte - uneingeschränkt empfehlen kann!!!

[berens]

Danke für hinzugekommenen Einträge.

Absolute Database scheint generell ein tolles Projekt zu sein, sich aber jetzt -bis auf Details- nicht viel mit FireBird zu geben, dazu gibt es ja hier im Forum auch einige Beiträge, u.a. https://www.delphipraxis.net/147300-...die-frage.html . Ich will auf keinen Fall ADB schlecht reden, aber das Bauchgefühl sagt mir, dass die Jungs&Mädels von FireBird sich -auch wenn OpenSource- komplett auf ihr Kerngeschäft konzentrieren können und alle Energie für den Datenbankserver zur Verfügung haben, wohingegen ADB -auf den ersten Blick- so wirkt, wie eine von vielen Komponenten von TMS oder LMD... Keine externen Tools/Schnittstellen, nur für Delphi, und "Know-How" für Administrator und Probleme "nur" bei den Entwicklern (Herausgeber und die Programmierer als "Nutzer"), nicht bei den Nutzern oder Administratoren der Kunden. Ich will das auf keinen Fall schlecht reden; lediglich, naja... bemerken. Wenn die Datenbankproblemlos läuft - alles gut. Wenn's ein Problem gibt kann einem der ein oder andere Admin eines Kunden bei SQL vielleicht weiterhelfen.

Was ich noch wichtiges vergessen habe zu erwähnen:
Windows hat immer noch einen netten Bug, wo trotz fortlaufender Recherchen Netzlaufwerke manchmal die Verbindung verlieren - rotes X vor dem Laufwerksbuchstaben. Im Windows Explorer hilft ein einfacher "Klick" drauf, schon wird der Inhalt geladen. Diesen "Klick" kann man programmiertechnisch nur durch sehr viel gemauschel nachstellen (unsichtbares Öffnen einer unsichtbaren Windows-Explorer instanz auf diesem Netzlaufwerk und dannach TaskKill), und das leider auch nicht immer zuverlässig, bzw. die TAdoConnection kann sich dann nicht unbedingt neu Verbinden lassen. DriveExists und FileExists liefern dann einfach immer False zurück, bis das Programm neu gestartet wird. Da dieses Problem unabhängig von dem Datenbanksystem auch in Zukunft immer wieder auftreten wird, würde ich schon sagen, dass ein Server via TCP/IP her muss, und dateibasierte Datenbanken /via Netzlaufwerk/ nun in der Entscheidungsfindung eher ein Ausschlusskriterium sind. Korrigiert mich...

Ich glaube, letztendlich wird es auf FireBird oder MS SQL Express hinauslaufen.

Zu meinen Fragen:

1) Können auf Beide -beispielhaft!- bis zu 50 Clients gleichzeitig zugreifen?
> Laut https://www.mcseboard.de/topic/14685...l-db-connects/ gibt es keine Beschränkungen bei der Clientzahl bei SQL Express (bzw. 32tausend). Somit sollten beide Systeme geeignet sein. Somit erledigt.

2) Frage nach der Stabilität/Inkonsitenzen speziell Firebird unter den o.g. Aspekten, bzw. störungsanfälligkeit von MS SQL (Dienst/Agent startet nicht, Port nicht erreichbar, Datenbankdatei-Probleme, ...)
> Erfahrungswerte? Irgendwer?

3) Wie einfach ist das Deployment des Server über meinen Installer? Rechtliche Probleme / Folgekosten / Lizenzierung bei Firebird <--> MS SQL Express?

> Lassen wir bei Microsoft mal die lizenzrechtliche Frage außen vor. Der SQL-Express Installer ist ausschließlich als Online-Installation (300MB Download) erhältlich, Offline-Installer gibt's afaik zwar auch im MSDN, aber das würde unser Installationspaket ja auch auf satte ~330 MB aufblähen. Entweder müsste man einen Assistenten für die Installations des SQL-Servers einprogrammieren (Link zum Download, Anleitung, ...) oder sich was anderes einfallen lassen. Eine kleine, und vor allem: schnelle Demo-Installation und Teststellung unserer Software wäre für technisch nicht versierte Interessenten dann schon ein großes Hindernis --> kein Kauf. Das wäre wiederum ein klarer Vorteil für FireBird. Ich muss das mal ne Nacht drüber schlafen und das mit dem Kollegen besprechen...

[scrat1979]

Also ich würde auch für Firebird plädieren. Da hast du auch lizenztechnisch keinerlei Probleme. Ob sich die Installation der Clients in deine Installation integrieren lässt (also nicht lizenztechnisch sondern rein technisch) kann ich dir nicht sagen. Als Zugriffskomponenten kann ich dir aus eigener Erfahrung IBDAC von DevArt ans Herz legen. Auch hier entstehen dir für die einzelnen Installationen keine weiteren Folgekosten. Preislich völlig okay, für etwas mehr Geld gibt es den Source auch dazu.

Viel Erfolg bei deinem Vorhaben.

Auch für FireBird sprechen die Cracks hier im Forum