Einfache lokale Datenbank – bitte um Entscheidungshilfe!

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

[hans65]

Eigentlich werden alle TurboPower-Komponenten zeitnah aktualisiert (https://github.com/TurboPack) und auch über GetIt angeboten. Deshalb dachte ich, das betrifft auch BTreeFiler. Aber genau dieses eine Produkt wird nicht gepflegt. Kennt jemand den Grund?

[TigerLilly]

Na ja, manche Sachen kommen einfach in die Jahre.

Schau dir mal MS SQL Express mit Tools an. Kostet nix, ich leicht zu verwenden und sowas von genial. Oder wie schon genannt Advantage, NexusDB etc.

Kleb nicht an dem, was du kennst!
Prüfe alles kritisch, was älter als 2 Jahre ist.

[mkinzler]

Für seine Zwecke dann doch eher MSSQL compact. Oder halt SQLite oder FireBird embedded. Das letztere hat den Vorteil, dass die Datenbank auch vom entsprechenden großen DBMS weiterverwendet werden kann (Programm bedarf hierfür auch keine Änderung).

[TigerLilly]

Zitat:

Für seine Zwecke dann doch eher MSSQL compact

Ich habe den bewusst nicht angeführt, weil ich finde, dass es zum kennenlernen einfacher ist, wenn du eine eigenständige Umgebung hast + was ausprobieren kannst, bevor es ans programmieren geht.

Aber im Kern geht´s darum, dass es viel und gutes NEUES gibt + dass sich die Lernkurve bezahlt macht.

[Delphi.Narium]

Ob die Datenbank nun SQL kann oder nicht, ist doch eigentlich wurscht.

Wenn man kein SQL nutzen will, dann nimmt man halt 'ne Komponente, die ein Nachfahre von TDataSet ist und nutzt dort Locate, Append, Edit, Post ... Damit kann man alles wesentliche erledigen. Wie es letztlich datenbankseitig umgesetzt wird, sollte dem Entwickler eigentlich egal sein. (Man kann also durchaus ohne SQL auf z. B. Oracle zugreifen und damit vollständige Datenbankanwendungen schreiben, ohne auch nur 'nen Hauch von Ahnung von SQL zu haben )

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.

Achso: gehöre auch zu den "alten Säcken", die aus den "Vor-SQL-Zeiten" stammen, aber deshalb möchte ich bei 'ner Datenbankanwendung trotzdem nicht auf SQL verzichten. Meine Erfahrung: Mit SQL ist vieles leichter und wenn SQL mal langsam ist, hat man was falsch gemacht. Und das dann SQL vorzuwerfen, ist der falsche Ansatz.

[jobo]

Kaum ein paar Worte geschrieben, schon timeout, neues Login und schon dutzende neue Beitrage, wie auch immer, hier mein Senf

ot
Ich bin ja kein Freund davon, den TE die Anforderungen im Mund rumzudrehen, daher ot, aber ich finde die Anmerkungen von TiggerLilly ganz treffend.

Dazu noch von mir:
1. was ist genial an MSSQL Express? (reine Neugier, vlt. nützt es auch dem TE)
2. alle 2 Jahre prüfen find ich ok, aber das ist kein Selbstzweck, ich mag Systeme (und Unternehmen) die für langlebige Verfahren stehen.
3. MS steht nun nicht unbedingt für 2., besonders was "gelegentliche Wechsel der favorisierten, supporteten Connectivity" angeht
4. Der Schritt Richtung SQL mag ratsam sein (für mich sowieso), aber eine file basierte Technologie? Dann lieber eine, die "seamless" zum Server mutieren kann (z.B. Firebird). Technologiewechsel, Umlernen, Protokollprobleme entfallen. (Filebasierte Datenbanken benötigen m.E. eine unnötige und mindestens historisch anfällige Zwischenschicht)
5. Der TE will "32, vielleicht auch später 64 bit". Da klingt etwas von vorausschauen durch, m.E. ist die Grundanforderung nach einer filebasierten, seqentiellen DB aber nett gesagt das Gegenteil, recht old school
6. "vielleicht auch kleine Bilder", dann später doch auch große, und weil sie lokal so leicht zerstört werden können, selbst versehentlich, kommen sie natürlich in die DB, nicht daneben und dann geht es langsam dahin, das System, das eigentlich fast nichts können muss..
7. aus 6. und unbekanntem Einsatzweck heraus ergäbe sich vielleicht auch noSQL DB, allgemein dokumentbasierte oder Mischsysteme als Alternative.

(Für den TE, bitte einfach als Hinweise, Denkanstöße ansehen und mit dem wirklichen Einsatzzweck/Perspektive abgleichen)
/ot

[MichaelT]

Die heißen heute NexusDB, wenn ich mich nicht irre. (ehem. Flash Filer)

Zitat von hans65:

Eigentlich werden alle TurboPower-Komponenten zeitnah aktualisiert (https://github.com/TurboPack) und auch über GetIt angeboten. Deshalb dachte ich, das betrifft auch BTreeFiler. Aber genau dieses eine Produkt wird nicht gepflegt. Kennt jemand den Grund?

[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 (?)