Einfache lokale Datenbank – bitte um Entscheidungshilfe!

[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