Einfache lokale Datenbank – bitte um Entscheidungshilfe!

[Andreas13]

Hallo zusammen,

Zitat von scrat1979:

Da kostenlos kein Kriterium ist (oder habe ich es überlesen?) werfe ich auch mal Absolute Database in den Raum. Compiliert direkt in die EXE, benutze ich für einige kleine Projekte seit Jahren und bin voll zufrieden!

@scrat1979 (Michael Kübler)

10^3 x Danke Michael: das war der entscheidende Tipp für mein Vorhaben!
Zunächst habe ich NexusDB getestet: Leider ist es für einen mich als Datenbank-Anfänger viel zu komplex und vor allem sehr umständlich in der Handhabung.
„Absolute Database“ Absolute Database ist wohl die Lösung für meine Aufgabenstellung. Sie ist einfach in der Benutzung, (fast) alle Demos funktionieren und sind sehr informativ. Die Hilfedatei war/ist für mich eine wirkliche Hilfe.

Zitat von jobo:

…
6. … , nicht daneben und dann geht es langsam dahin, das System, das eigentlich fast nichts können muss..

Ihr DB-Experten arbeitet bestimmt mit weltweit verteilten Datenbanken oder im Bereich von BigData. Meine Anwendung ist nur „Very Little Data“. Damit Ihr meinen DB-Bedarf neben der obigen Kurzspezifikation besser verstehen könnt, folgt kurz mein Projekt.

Als Ingenieur erstelle ich seit Jahrzehnten technische-wissenschaftliche Berechnungen aus dem Bereich der mechanischen, thermischen und chemischen Verfahrenstechnik und der Anlagenplanung, die ich als Funktion über DLL‘s in Excel einbinde. Meine „Programme“ sind daher keine eigenständigen Programme mit eigener Oberfläche, sondern laufen als „Bestandteil“ von Excel. Der Benutzer gibt seine Eingangsdaten in Excel ein, schickt die Funktion ab, und die Ergebnisse der oft recht umfangreichen Berechnungen landen gleich in der Excel-Tabelle.

Diese Berechnungen benötigen als Input meistens eine große Anzahl diverser Stoffdaten wie z. B. Dichte, Viskosität, Wärmeleitfähigkeit, Wärmekapazität, Oberflächenspannung, Dampfdruck, kritische Daten etc. Etliche dieser Stoffdaten sind Funktionen der Temperatur, des Druckes und der Konzentration der einzelnen Komponenten (Diese Zusammenhänge liegen oft in Form empirischer Gleichungen mit zahlreichen Koeffizienten vor). Darüber hinaus werden auch noch Kenndaten diverser Apparate (Wärmeaustauscher, Behälter, Destillationskolonnen, Rohleitungen, Pumpen, Gebläse, etc.) benötigt, die z. T. genormt sind (= umfangreiche Tabellen) und oft vom Druck im System abhängen (z. B. Wandstärke der Rohleitungen, Behälter etc.). Bei manchen Aggregaten (z. B. Pumpen, Gebläse, etc.) steckt ihr Betriebsverhalten in diversen Diagrammen (z.B. „Kennlinien“) etc. Hinzu kommen noch diverse chemische Analysendaten (z. B. Rohstoffe, Hilfsstoffe, Endprodukt, Abfallstoffe etc.), die für den jeweiligen Prozeß relevant sind.

All diese Daten (und oft noch mehr) werden in meinen Berechnungen benötigt. Da ich die Programmierung – als NICHT-Informatiker – lediglich als Hobby und zugleich zur Erstellung von Arbeitserleichterungen („Tools“) für die Verfahrens-& Chemie-Ingenieure praktiziere, brauche ich eine hohe Zuverlässigkeit und vor allem Beständigkeit. Auch ich stamme noch aus „MS-DOS-Zeiten“ und habe bereits mehrere Systemwechsel (… CP/M, MS-DOS, Windows-16-Bit, Windows32-Bit) hinter mir, und konnte jedes Mal ein Scherbenhaufen meiner früheren Programmier-Arbeit erleben und alles wieder von vorne beginnen: Deswegen war / ist Beständigkeit für mich extrem wichtig.

@TigerLilly: Ich kann meine Software-Entwicklungen nicht alle zwei Jahre umstellen, weil damit täglich gearbeitet wird...

Ich habe eine relativ „große“ Sammlung (= für Euch nur „Very Little Data“) oben genannter Stoff- und Apparate- und Anlagen-Daten, vorwiegend in Excel und auch in Access. Und diese Daten möchte ich in einer einfach zu handhabenden Datenbank so ablegen, daß meine Berechnungsroutinen die erforderlichen Daten direkt aus dieser Datenbank holen können.

Daher hat Jo (@jobo) Recht, indem er feststellt, daß meine DB „eigentlich fast nichts können muss..“.

Noch einmal vielen Dank für die lehrreiche Diskussion und die wertvollen Anregungen. Ich habe viel von Euch gelernt!

Gruß
Andreas

[hoika]

Hallo,
was spricht dann nicht für XML?
Es soll ja nur gelesen werden, wie ich es verstanden habe. (?)
Und der Nutzer soll das auch nicht so leicht ändern können (?)

[jobo]

Andreas, vielen Dank für die Infos. Klingt nach einem spannenden Arbeitsumfeld.
Mit Big Data habe ich eigentlich nichts zu tun, ein 3 stelliger Millionenbereich, darüber bin ich meinen Anwendungen noch nicht hinaus gekommen.
Eine Datenbank zu wechseln (Migration) ist an sich auch nicht so ein Problem, egal wie groß oder klein. Es dreht sich häufig um die Frage, wie tief sie im Code und in anderen Prozessen verstrickt ist oder auch DB spezifische Fähigkeiten im Programm genutzt werden. Also eher eine Frage von "Big Code". Was muss alles umgestellt werden, wenn das aktuelle Produkt Probleme bereitet.

So wie du es beschrieben hast, sehe ich da auch sowas wie XML, eher noch JSON. Dann kannst Du die Daten mit (fast) jedem Texteditor verwalten- es gibt jedenfalls sehr geeignete-, als Resource in Dein Programm einbauen oder was auch immer.

[Andreas13]

@ hoika
Hallo Heiko,

Zitat von hoika:

was spricht dann nicht für XML?
Es soll ja nur gelesen werden, wie ich es verstanden habe. (?)
Und der Nutzer soll das auch nicht so leicht ändern können (?)

2 x Ja: Der Nutzer soll nur lesen können, nichts verändern. Allerdings sollen die Informationen nicht als Klartext, sondern mindestens binär (besser: verschlüsselt) gespeichert werden, da sich oft vertrauliche, proprietäre Meßdaten etc. darunter befinden. Der Anwender soll die Daten zwar benutzen, aber nicht einsehen können.
Mit XML habe ich bisher überhaupt keine Erfahrung…

@ jobo
Hi Jo,

Zitat von jobo:

…
So wie du es beschrieben hast, sehe ich da auch sowas wie XML, eher noch JSON. Dann kannst Du die Daten mit (fast) jedem Texteditor verwalten- es gibt jedenfalls sehr geeignete-, als Resource in Dein Programm einbauen oder was auch immer.

Das Problem ist bei JSON (und auch wohl bei XML) auch die Speicherung der Daten im Klartex-Format:

Zitat:

Der Nutzer soll nur lesen können, nichts verändern. Allerdings sollen die Informationen nicht als Klartext, sondern mindestens binär (besser: verschlüsselt) gespeichert werden, da sich oft vertrauliche, proprietäre Meßdaten etc. darunter befinden. Der Anwender soll die Daten zwar benutzen, aber nicht einsehen können.

@ Delphi.Narium

Zitat:

Und wenn es schon ohne "richtige Datenbank" sein soll, nehme man z. B. TClientDataSet, TDbf, KbmMemTable ... und hat damit jeweils dateibasierte Datenbanken, die keine zusätzliche Databaseengine benötigen. Alles, was gebraucht wird, wird in die Exe einkompiliert.

Auch TDbf (neueste Version tdbf701.zip, Stand: November 2015) habe ich getestet, doch – weiß Gott warum – liefert das Demo-Programm gleich beim Start eine „Access violation“. Daher habe ich es nicht weiterverfolgt. Nach diesem letzten (?) Mißerfolg habe ich mich schließlich an Euch gewandt und um Hilfe gebeten.

Danke & Gruß
Andreas

[jobo]

Verschlüsselst Du denn die Absolut DB Files bzw. deren Inhalte oder andere Formate?
Oder reicht die "Fremdheit" des Formats schon an sich?

Ich nehme an, in den Daten liegt zumindest zum Teil das Firmen Know How, aber auch JSON kann man ja wie jeden Text verschlüsseln.
Wir setzen JSON auch als Datentransferformat ein. Das geht auch ganz gut mit
>kleinen Bildern
>oder großen Bildern
Für Bilder oder allgemein Binärdaten ist sowieso ein Codierung wie z.B. bei Mailattachments notwendig (Mime Codierung).

[FaTaLGuiLLoTiNe]

Also wenn du wirklich nur reine Stammdaten hast, die vom Benutzer weder ergänzt noch geändert werden können und du am liebsten überhaupt keine weiteren externen Dateien haben möchtest, dann wäre es vielleicht zu überlegen, ob du deine Daten nicht lieber in vernünftigen Objektstrukturen, Listen und Dictionaries verwalten solltest, die beim Programmstart initialisiert werden. Oder evtl. als XML/JSON-Datei(en), die als Resource mit einkompiliert werden.

//edit: Ich sehe gerade, das mit den Resourcen hat jobo ja bereits vorgeschlagen.

[Sherlock]

Und XML erlaubt auch verschlüsselte Daten. So lange sie als Base64 vorliegen, sind alle Chiffrate zulässig. https://de.wikipedia.org/wiki/XML-Encryption
Über die Dateigröße könnte man sich Gedanken machen...

Sherlock

[Frickler]

Zitat von jobo:

Verschlüsselst Du denn die Absolut DB Files bzw. deren Inhalte oder andere Formate?
Oder reicht die "Fremdheit" des Formats schon an sich?

Absolute Database bietet verschiedene Verschlüsselungen (u.a. AES256). Die ganze Datenbank ist eine Datei (wie bei Access oder Firebird), aber es ist eine "dumme Datenbank", ohne Views, SPs, Trigger usw. SQL CRUD geht aber (zusätzlich zum ISAM Zugriff).

P.S.: SQLite kann auch verschlüsselt werden mit DISQLite oder LiteDac/UniDac. Ist aber beides nicht kompatibel zum offiziellen Standard (der ziemlich teuer ist), d.h. zum Entschlüsseln muss jeweils wieder die Bibliothek verwendet werden.

[scrat1979]

Zitat von Frickler:

Zitat von jobo:

Verschlüsselst Du denn die Absolut DB Files bzw. deren Inhalte oder andere Formate?
Oder reicht die "Fremdheit" des Formats schon an sich?

Absolute Database bietet verschiedene Verschlüsselungen (u.a. AES256). Die ganze Datenbank ist eine Datei (wie bei Access oder Firebird), aber es ist eine "dumme Datenbank", ohne Views, SPs, Trigger usw. SQL CRUD geht aber (zusätzlich zum ISAM Zugriff).

P.S.: SQLite kann auch verschlüsselt werden mit DISQLite oder LiteDac/UniDac. Ist aber beides nicht kompatibel zum offiziellen Standard (der ziemlich teuer ist), d.h. zum Entschlüsseln muss jeweils wieder die Bibliothek verwendet werden.

Natürlich ist AbsouteDatabase nicht die eierlegende Wollmilchsau, aber insbesondere IMHO für den Anfang und für kleine Projekte absolut Top! Der reibungslose Zugriff mit den entsprechenden Komponenten ist insbesondere auch für Anfänger sehr gut geeignet. Ich benutze es bei meinem Server für eine Termindatenbank mit ca. 60-130 Terminen pro Tag. Das Einlesen von 3 Monaten in eine entsprechende Objektliste, welche danach durch das Netzwerk gejagt wird, geht sehr schnell. Für andere Projekte benutze ich selbst auch Firebird mit den IBDAC-Komponenten. Auch spitze - vor allem die spätere Skalierbarkeit natürlich von Vorteil.

Schönes Wochenende