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

[IBExpert]

Wenn du dir mal konkret nahezu alles know how was man braucht, um die komplette firebird installation zu verstehen, in 2 stunden reinziehen möchtest, schau dir mal dieses video an https://www.youtube.com/watch?v=MIyA8xqTWi0

Große vorteile für dich bei firebird meiner Meinung nach:

-Installation als batch mit einer einzigen Zeile in dein setup integrierbar, erstellt dann sogar einen eigene instanz mit eigenem Namen und einem eigenen tcp ip port, kommt also mit bereits installierten älteren oder neueren Versionen überhaupt nicht in konflikt. ado kram benutz ich zwar nicht, aber aus der Delphi Welt heraus gibt es mit FireDAC oder devart.com unidac/ibdac sehr gute Bibliotheken, mit denen du nativ da dran kommst und auf dem Weg schnell potentielle ADO Probleme aufgrund von Microsoft updates oder sonstiger Gründe vermeiden kannst.

-Bei Firebird kannst du deine Installation wenn du willst auch komplett Ohne jegliches Setup laufen lassen, firebird im Applikationsmodus braucht gar nichts in der registry oder im Systemverzeichnis, deine eigene Firebird Instanz kann neben diversen anderen Firebird Versionen parallel laufen, ohne das deren Updates dein System zum Stillstand bringt. Sämtliche für Firebird erforderliche Dateien kannst du ohne irgendeinen regsvr32 schrott oder sonstwas an Registry Orgien zum laufen bringen und uneingeschränkt beliebig oft an jeden verteilen, es kostet niemals Geld und ist extrem einfach zu verstehen, daher extrem einfach zu warten. Eine komplette Applikation auch netzwerkfähig als ausgepacktes zip file zu verteilen ist mit Delphi exe, ein paar dlls für die nativen client libs firedac/ibdac und fb server im applikations modus technisch überhaupt kein Problem.

-50 User als Obergrenze von dir genannt ist weit davon weg, was Firebird als Obergrenze kann. Wir haben Installationen mit hunderten Usern und weit über einem Terabyte an Datenbankplatz in Benutzung. Wenn du deine SQLs und deine Datenbankmodel nicht völlig scheisse programmierst und die Firebird Hilfsmittel benutzt, um fehlende Indizes usw. zu erstellen, geht das alles auch ohne SPs, aber du wirst früher oder später sehen, das deren Vorteile doch immens sind. Weiter über eine Milliarde Datensätze in einer Tabelle sind sicherlich auch Limits, die du nicht so schnell erreichen wirst.

-Wie viele Datenbanken du einsetzt und wie groß deine Datenbanken sind, ist komplett unlimited.

-Bei entsprechender Programmierung ist Firebird komplett wartungsfrei, auch 24/7 , soweit das unter Windows überhaupt irgendeine Software ist, weil du bei aktuellen Windows Version gerne mal ungefragte Reboots wegen Zwangsupdates untergejubelt bekommst.

-Auch auf alle aktuellen Windows Versionen bekommst du noch eine 15 Jahre alte Firebird 1.5 Version zum laufen, wenn du es aus welchen Gründen auch immer mal brauchen solltest.




Was meiner Meinung nach deutlich gegen MSSQL Express spricht

-nach meiner Kenntnis haben alle mssql Express Editions ein Datenbank größen Limit von 10 GB, siehe https://docs.microsoft.com/en-us/sql...BoxScaleLimits

Wenn dir das reicht, dann ok, aber wenn du deinem Kunden bei 9,9 GB so langsam erklären musst, das er langsam mal den Geldbeutel öffnen muss, würde für mich nicht in frage kommen, weil das immer das negative Marketing ist, du bist schuld weil du das nicht gleich von anfang an gesagt hast usw. (auch wenn dem nicht so ist).

-Wenn Irgendein Kunde dann deine Software einsetzt und von server A auf Server B umziehen will, server B aber die neueste OS Version hat und nicht die, die deine Software bisher als einzige unterstützt, wird es ganz schnell passieren, das dein Support sich ohne Ende damit beschäftigen muss, den Kram bei diesem Kunden zum laufen zu bringen. Dafür wird er garantiert wenig bis gar nicht zahlen wollen.

[TurboMagic]

Bei der Nutzung von Firebird könntest du die in Delphi enthaltenen FireDAC Zugriffskomponenten benutzen. Die kapseln auch das DB Backup/Restore von Firebird. Davon gibt's inzwischen eine alte und neue Variante. Ich habe mich bisher nur mit der alten auseinandergesetzt und Backup/Restore sind dabei recht einfach.

Den Firebird Installer kann man auch "silent" aufrufen. Meine Anwendung benutzt einen Inno Setup Installer (FB vermutlich auch) und der enthält das Setup von FB und führt es "teilweise silent" aus. Einziges Problem ist die erkennung ob ein Neustart nach der Installation nötig ist. In 99% der angezeigten Fälle scheint das nicht der Fall zu sein, in 1% wohl schon...

Es ist auch zu beachten, dass auf dem Zielrechner nicht schon ein FB Server von einer anderen SW läuft (habe in der Arbeit genau einen Rechner mit einer speziellen anderen gekauften SW), dann gibt's mit dem Port des Dienstes ein Problem. Da hab' ich mich bisher aber noch nicht gekümmert.

FB gibt's auch in einer Embedded Variante, dann liefert man einfach die nötigen Dateien so mit und inzwischen kann das glaube ich sogar mehrere Verbindungen unterstützen, was dieser embedded Variante aber fehlt ist der Login soweit ich mich erinnere.

[TigerLilly]

Ich kann nur über meine Erfahrungen mit MSSQL Express reden. Und das hat sich für uns sehr bewährt. Unsere Software wird als Einzelplatzversion (Server+Client auf einem Gerät) oder eben im Netz betrieben. Das ist gut skalierbar, und nahezu ohne Probleme, eigentlich tauchen nur 2 Dinge auf: Der Versuche, den SQL Server zu installieren, wenn noch Updates "pending" sind. Und manchmal dreht Windows den Dienst einfach ab + er muss einmal manuell gestartet werden. Unsere Kunden sind von Studenten bis hin zu 50 User Firmen alles dabei. Das Setup ist von uns automatisiert + läuft eigenständig durch. Unsere Software wird auch an Fachschulen eingesetzt, da installiert dann ein ganzer Jahrgang die Software auf den Privat-PCs. Bei ca 1% gibt´s Handlungsbedarf + dann ist es zu 99% ein fehlender reboot wg der Updates.

Die Größenbeschränkung gilt pro DB, im schlimmsten fall macht man weieter DBs, lagert Tabellen dorthin aus + bindet die über SYNONYM ein. Das geht völlig transparent + ohne die APP ändern zu müssen.

Express ist kostenfrei + kann genauso gut im Netz eingesetzt werden.

[Delphi.Narium]

Auf FireBird kann man (wenn's denn sein muss) auch über ODBC zugreifen. Dann muss man im Programm nur den Connectionstring ändern. Ist der konfigurierbar hinterlegt, muss man nur die Konfiguration ändern.

Neben der Installation von FireBird muss dann auch der ODBC-Treiber installiert werden.

Man kann sich dann damit erstmal um die "Baustelle" Datenbankwechsel von Access auf Firebird kümmern und später, wenn es dann doch erforderlich sein sollte, um den Austausch der Datenbankkomponenten im Programm.

'ne MDB kann man auch ohne Access packen, einfach 'ne passende Prozedur ins Programm einbauen: Delphi-Praxis: Access datenbank komprimieren und reparieren

Du schreibst weiter oben, dass den ganzen Tag auf die MDB zugegriffen wird. Auch die ganze Nacht? Das ganze Wochenende?

Wenn es irgendeinen "Wartungszeitraum" gibt: 'nen Service schreiben, der den Job übernimmt oder ein Programm, das das per Taskplaner erledigt.

Achso: Ist der Connectionstring konfigurierbar hinterlegt, müssen nicht alle Kunden gleichzeitig wechseln und Du musst nicht für die Zeit des Wechsels zwei Programme vorhalten: Eins für Access, eins für FireBird.

Solange in den SQL-Statements nix absolut accessspezifisches genutzt wird, sondern nur Standard-SQL, sollte das transparent sein. Klar: Tabellenstruktur, Spaltennamen, ... müssen identisch sein.

[Billa]

@Service: wir haben das mal flexibel gelöst.
Jeder erfolgreiche Aufbau einer Verbindung erhöht einen Zähler, jeder Abbau verringert ihn. Wenn der Zähler 0 ist, darf man bei Bedarf den Service anschmeißen. Das setzt ein anderes Flag in der DB. Dann darf sich kein Client verbinden. Nach Beeden des Service wird das Flag wieder entfernt und man kann weiter arbeiten.
Das war nur eine Zwischenlösung bei einem "24/7"-Programm (es gab keine vorhersehbaren Zeiträume) vor der Umstellung auf Firebird....

[Hobbycoder]

Zitat von Billa:

@Service: wir haben das mal flexibel gelöst.
Jeder erfolgreiche Aufbau einer Verbindung erhöht einen Zähler, jeder Abbau verringert ihn. Wenn der Zähler 0 ist, darf man bei Bedarf den Service anschmeißen.

Das haben wir in einer Anwendung zwar ähnlich, aber doch etwas anders gelöst. Denn wenn ein Client abstürzt, dann kann er seinen Zähler nicht mehr rausnehmen.
Wir haben extra ein Tabelle mit den Felder Clientname, Datum/Zeit. Startet ein Client, so trägt er sich mit Namen und Zeit ein. Alle 5 Minuten aktualisiert er seine Zeit in dem Datensatz. Wenn er sich anmeldet, löscht er seinen Datensatz.
Stürzt er ab, prüft er beim Eintragen ob noch ein alter Datensatz vorhanden ist und übernimmt diesen.

Schaut nun der Service drauf, kann man a) sofort die Toten Datensätze erkennen (Zeit ist älter als 5 Minuten) und b) gezielt die User ansprechen, die noch drin sind.

[berens]

Hallo zusammen und nochmal herzlichen Dank für die zahlreichen -sehr hilfreichen- Antworten.

Zur allgemeinen Erheiterung möchte ich noch das Best-Of der Besprechung mit meinem Kollegen (Vetrieb) zu den nun zur Verfügung stehenden Alternativen (bei Access bleiben, MS SQL (Express), Firebird) wiedergeben: "Dann implementier doch einfach alle Drei. Bei jeder Datenbankabfrage vorher ne kleine if-then Abfrage für die jeweils benötigten Komponenten - kann auch nicht mehr Arbeit sein als nur die eine neue Komponente zu implementieren.". Ja ne is klar.

Ich meine vom Grundgedanken hat er ja nicht unrecht: Kleine Kunden könnten auf "Einzelplatzlösungen" (1 Infobildschirm, 1 Redaktions-PC) ja auch in Zukunft -mit den bekannten Mankos- schon noch auf .mdb-Dateibasis weiterarbeiten. Auch die Demoinstallationen bei Interessenten wären auch hier noch schnell und einfach möglich. Und die Ansteuerung von MS SQL und Firebird über den ODBC-Treiber (danke @Delphi.Narium , nochmal gute Idee) würde ja die Änderungen (größtenteils) auf die TAdoConnection beschränken. Der Benutzer könnte ja dann mit der klassischen Installation anfangen (lokale Datenbank), und -auf Wunsch oder Anraten von unserem Support (mir ) auf ein größeres System migrieren. Den FireBird Server könnte man ja als optional installierbaren Punkt in unserem Installer anbieten, oder als zusätzliches Stand-alone Downloadmodul (oder natürlich den offiziellen Download verlinken). Den ODBC-Treiber für Firebird würde ich dann wahrscheinlich bei allen Installationen zwangs-mitinstallieren.

Wahrscheinlich würde ich die Migration so planen:
1) Einen Assistenten anbieten, um die Datenbankverbindung auswählen zu können (.mdb / MS SQL / Firebird), also entweder Dateipfad oder Server/IP, User/Pass (wie speichert man das wieder sicher?) , der dann zukünftig von der TAdoConnection verwendet wird.
2) Einen Upscaling-Assistenten anbieten, der in der leeren Datenbank auf dem Firebird/SQL Server alle notwendigen Tabellen erzeugt bzw. auf den aktuellen Stand bringt, und -nach Möglichkeit- direkt alle Daten 1:1 rüber kopiert.
3) Auslagern aller direkten Datenbankzugriffe von den jeweils Themenbezogenen Units in eine (oder mehrere) Datenbank-Units, wo situationsbezogen (als Prozeduren mit entsprechenden Parametern) der SQL-String und die Parameter vorbereitet werden, so dass ich in den themenbezogenen Units nur mit (q = TAdoQuery --> q.First, q.Next, q.EOF, q.FieldByName('Text1').AsString := 'Test'; q.Post, q.Close etc.) arbeite, aber alle Datenbank-nahen Befehle (q.SQL.Add('...'); q.Parameters.ParamByName(...) ) in dieser einen(?) Datenbankunit bleiben. Das hätte den Vorteil, dass ich recht einfach und übersichtlich hierfür dann Unit-Tests schreiben kann, die man ggf. auch zur Laufzeit beim Kunden laufen lassen kann, um eventuelle Inkompatibilitäten zu verschiedenen MS SQL / FireBird Versionen aufdecken zu können, die ggf. beim Kunden auftreten können. Ich rede hier nicht von eventuellen Bugs, aber von Erfahrungswerten nach dem Motto: Bei Access-SQL müssen/können bei Abfragen Tabellen/Feldnamen in [eckigen].[Klammern] stehen, WHERE TEXT1="" muss in FireBird-SQL evtl. WHERE TEXT='' lauten etc.etc. Halt diese kleinen Spitzfindigkeiten, bei denen ich mich auch gerne früher schon and den SQL92 Standard gehalten hätte, aber Access manche Sachen eben doch explizit anders haben will... Beispiel: Eine Tabelle nennt sich "Layout". Böses Wort, könnte als systemreserviert Interpretiert werden. Wenn ich nun "alle" meine SQL-Abfragen/Befehle/Unit-Tests beim Kunden nacheinandere ablaufen lasse(n kann), sehe ich z.B. falls

Code:

CREATE TABLE [Layout] ...

auf dem einen System fehlschlägt, und

Code:

CREATE TABLE "Layout" ...

auf dem Andern, und entsprechend darauf reagieren.

Somit wären denke ich mal gute Voraussetzungen für die neue Hauptversion geschaffen, und man kann diese ganzen Schritte auch wirklich Schritt für Schritt gehen, ohne das komplette Programm von jetzt-auf-eben "anders" zu haben. Die [zusätzlichen] Firebird-Komponenten wären das Sahnehäubchen, aber ich glaube die paar (Milli-) Sekunden leistungssteigung stehen -im Moment zumindest- in keinem Verhältnis zur der vorteilhaften Dreigleisigkeit über ADO/ODBC. Später aber gerne!

@Delphi.Narium: Danke für den Link zum komprimieren und reparieren der Datenbank. Dieses Verfahren setzen wir afaik bereits ein, dies scheitert jedoch tatsächlich in der Praxis daran, dass TADOConnection die Datenbankverbindung zum Reparieren nicht aufbauen kann, weil die Datenbank gerade defekt ist. Naja, Offtopic, anderes Thema.

Delphi-Quellcode:

    v := CreateOLEObject('JRO.JetEngine');
    try

      try
        // Datenbank komprimieren, diese wird unter neuem Dateinamen gespeichert
        V.CompactDatabase('Provider=Microsoft.Jet.OLEDB.4.0;Data Source=' + _DB,
                          'Provider=Microsoft.Jet.OLEDB.4.0;Data Source=' + CompressedFileName);
      except
        Result := False;
      end;

Zur Offline-Erkennung der Clients hatte ich ein ähnliches System wie @Hobbycoder, allerdings war es zuletzt am häufigsten vorgekommen, dass genau eben DURCH das Schreiben dieses "Status" in die Datenbank diese "zerstört" wurde. Gefühlsmäßig behaupte ich mal, dass die Existenz der MeineDatenbank.ldb - Datei schon ein guter Indikator ist, ob die Datenbank gerade gewartet werden kann (wenn sie existiert, dann nein). In der Regel läuft das Löschen der Datei -soweit ich mich erinnere- auch relativ zuverlässig. Klar kann "mal" ein Client abstürzen und sie wird nicht gelöscht (?), aber der nächste Client korrigiert das afaik, sobald dieser sich dann trennt. Somit sollte zumindest 1x die Woche eine "Offline-Wartung" technisch erkennbar und machbar sein - mit MS SQL oder Firebird hoffentlich wirkliche nie mehr notwendig!


Ich hake jetzt mal "offene Frage" ab, und bedanke mich herzlich bei allen Teilnehmern für die guten Beiträge, die meiner Meinung nach sehr gut zu einer klaren Richtung mit einem umsetzbaren Fahrplan geführt haben!

Zu der "Problematik", dass ich mir den Connection-String nun pro Benutzer/PC mit ggf. ServerIP, Name und PASSWORT merken muss, gibt es ja im Forum zahlreiche Beiträge, ebenfalls mit dem Verweis auf den Mixed-Mode, Trusted-Login etc., bei denen Windows ja einfach die Anmeldedaten (bzw. das Token) des aktuellen Benutzers verwendet. Falls ihr gerade ein "Best-Practise" zur Hand habt, wie der Benuzter die Datenbankverbindung an sinnvollsten (einfach!) konfiguriert,
1) ohne den kompletten TAdoConnection.ConnectionString-Assistenten zu verwenden
2) (Sicheres?) abspeichern dieses Strings trotz/mit Benutzername/Passwort?
bin ich natürlich total dankbar dafür, ich scheue mich aber natürlich auch nicht davor, brav die SuFu zu verwenden.

Nochmals Danke!

[Blup]

Wir haben die Verbindungsinformationen in einer zentralen Konfigurationsdatei auf einem Server abgelegt. Diese Datei ist verschlüsselt, der Schlüssel ist nur der Anwendung bekannt. Auf den Arbeitsstationen wird nur der Pfad (bzw.Link) zu dieser Konfigurationsdatei ausgewählt und gespeichert. Die Konfiguration muss so nur einmal vorgenommen werden.

Wir unterscheiden zwischen Datenbankbenutzer und Anwendungsbenutzer. Datenbankbenutzer gibt es für die Installation nur einen (Name und Kennwort muss nur die Anwendung wissen). Die Anwender und deren Passwörter(bzw. Hashwert) sind in der DB gespeichert und werden durch die Anwendung verwaltet.

[Rolf Frei]

Ich nutze seit vielen Jahren ElevateDB. Diese ist in Delphi geschrieben und ist daher eigentlich die beste Lösung in der Delphi Welt. Je nachdem wie man es einsetzt (File oder C/S), braucht es keine Installation. Alles ist in der EXE enthalten, also die ganze Engine. Die DB bietet das meiste was auch die "grossen" DB's bieten, also z.B. Replikation, Backup, Stored Procedures/Functions, Einbindung eigener Funktionen über DLL's, die nicht per Stored Procedures zu machen sind.

www.elevatesoft.com

Ich nutze das seit Jahren und bin super glücklich damit, weil ich da alles habe, was ich brauche und ich da keine komplizierte Einrichtung der DB benötige.

[mytbo]

Wenn du die ORM Funktionalität von mORMot verwendest würdest, müsstest du beim Zugriff auf eine bestimmte Datenbank nur die jeweilige Connection anpassen. Um den Rest kümmert sich das Framework. Im Samples Verzeichnis findest du unter "12 - SynDB Explorer" die Implementierung eines Datenbank Explorers. Im Beispiel stellst du eine Verbindung mit dieser Funktion her:

Delphi-Quellcode:

function TryConnect(C: TSQLConnection; ...): boolean;
const 
  CONN_CLASSES: array[TExpConnectionType] of TSQLDBConnectionPropertiesClass = (
    TSQLDBOracleConnectionProperties,
    TOleDBOracleConnectionProperties,
    TOleDBMSOracleConnectionProperties,
    TOleDBMSSQLConnectionProperties,
    TOleDBConnectionProperties,
    TSQLDBSQLite3ConnectionProperties,
    TOleDBJetConnectionProperties,
    TODBCConnectionProperties,
    TSQLDBWinHTTPConnectionProperties,
    TSQLDBZeosConnectionProperties);
...   
begin
  ...
  Props := CONN_CLASSES[C.Connection].Create(C.Server, C.Database, C.UserName, Pass);
  ...
end

Und mit einfachen Funktionsaufrufen kannst du einen Datensatz in der DB anlegen, aktualisieren oder löschen. Das Schöne ist, man muss sich um nichts kümmern. Und wenn handgeschriebenes SQL erforderlich ist, steht das Framework nicht im Weg.

Delphi-Quellcode:

type
  TSQLMeineDaten = class(TSQLRecord)
  ...
  published
    property Aktiv: Boolean read FAktiv write FAktiv;
    ...
  end;

var
  dataObj: TSQLMeineDaten;
begin
...
  .AddOrUpdate(dataObj);
  .Delete(TSQLMeineDaten,  dataObj.ID);
  .RetrieveList<TSQLMeineDaten>('Aktiv = ?)', [isAktiv]);

Bis bald...
Thomas