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

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

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