Datenbank für schnelle Bilder, Vorschläge bitte.

[KodeZwerg]

Hallo Community!
Ich schreibe gerade ein Programm was anhand von Daten ein Bild erstellt.
Das ein Bild nicht ständig neu berechnet werden muss wenn Daten gleich bleiben, so dachte ich mir kreiere ich eine Datenbank dafür.
Ziel soll sein eine DB zu haben die mir schnell das Image zurückgibt und mit Datensätzen von 500k bis 1mio keine großen Probleme hat.

Datenbank sollte diese Möglichkeit bieten:
1. Einen Namen zu speichern damit ich es im nachhinein Daten zuordnen kann.
2. Ein/Zwei Bild(er) zu speichern (darum geht es ja Eigentlich) und schnell laden zu können
- noch sind Bilder unkomprimiert, falls eine Kompression den Ladevorgang beschleunigen kann, mache ich es

Es wird nur lokal gearbeitet und es wird keine DB Anzeige im Hauptprogramm existieren.
Es wird nur unter Windows gearbeitet.

Programm Ablauf:
- Programm starten
- Programm lädt Daten und schaut in DB anhand des Namens ob es dafür schon ein vorberechnetes Bild gibt
- Falls Möglich, das man auch optional ein zweites Bild dem Datensatz zufügen kann, das wäre toll
- entweder Bild neu Berechnen oder DB-Bild laden
- Programm beenden (oder weitere Daten laden etc)

Hauptprogramm DB features, alle transparent, User wird darauf keinen Einfluss haben
- Datensatz erzeugen
- Datensatz laden
- Datensatz löschen
- Datensatz updaten
- Datensatz speichern
- Datensatz schnell nach Namen durchsuchen
- eventuell eine doch User-Steuerbare Möglichkeit die DB neu zu schreiben um verwaiste Datensätze zu entfernen bzw alphabetisch sortieren zu lassen, falls das ein Suchen beschleunigen würde

Was schlagt ihr vor für welches Framework ich mich entscheiden sollte?
Momentan ist nur Delphi Tokyo 10.2.3 voll installiert, keine weiteren DB Komponenten.

Für Ratschläge wäre ich dankbar, Fragen beantworte ich auch gerne falls das oben zu lütt bzw falsch an Information ist.

[Schokohase]

Bis jetzt sehe ich hier nichts wo eine Datenbank benötigt wird.

Die Direktablage auf der Festplatte tut es da auch.

Für die Ablage im Dateisystem schaut man sich an, wie so ein TDictionary seine Daten intern verwaltet (über Buckets).

[mkinzler]

Datenbank hat den Vorteil, dass alles nur eine oder 2 Dateien abgelegt wird. Bei der genannten Anzahl solte aber jedes DBMS geeignet sein. Gut eines mit BLOB-Unterstützung.

[Delphi.Narium]

Embeddedversion von Firebird, dann brauchst Du nichtmal 'nen Datenbankserver aufsetzen, da der quasi Teil Deines Programmes wird.

Aber: Solltest Du irgendwann mal sagen: Oh, da Programm wird jetzt ein Mehrbenutzersystem, dann tauschst Du die Embeddedversion gegen 'nen Firebirdserver aus, die Datenbankdatei kannst Du weiterhin nutzen, eine Konvertierung, irgendwie geartete Datenübernahme ... ist nicht notwendig.

Und schnell ist die eigentlich auch.

Und Bilder ablegen kann sie auch: https://firebirdsql.org/refdocs/langrefupd21-blob.html

[KodeZwerg]

Danke für Eure Aussagen, embedded mit Blob hört sich an nach dem was ich brauche, hoffe ich
Dem werde ich Nachgehen und zur Post #2, wir haben einen Ordner mit schlapp 450000 Dateien, Ziel soll eine Datei sein die alles schnell bereithält, ich könnte auch Zippen aber das geht mir zu sehr auf die Performance bei Veränderungen.
Im Nachhinein ist mir eingefallen das ich noch eine Definition pro record brauche, einen Hash oder CRC Wert der original Daten damit ich auch auf Veränderungen reagieren kann
Vielen Dank für Feedback!

Ps: Daran soll später nie was verändert werden, Bild(er) plus Name plus CRC in die DB und per Hauptprogramm gesteuert ohne da direkt DB spezifische Knöpfe/funktionen bereitzustellen, alles im Hintergrund.

[mkinzler]

Firebird ist definitiv gut geeignet.

[KodeZwerg]

Ich bin bereits hier aber finde keine embedded Version, muss ich zu einer älteren als Firebird 3.03?

Hat sich erledigt, gerade gefunden/gelesen ist im Paket/gibt nur ein Paket, sorry!

[mkinzler]

Ja, ab v3 gibt es keine speziellen embedded (server) Client mehr.

[KodeZwerg]

Um Deine Kritik zu beantworten:
1.
Ich war auf der Hersteller-Seite und mir wurde eine embeddedVersion empfohlen, auf der Hersteller-Seite ist es nicht gleich offensichtlich da es für mich neu ist frage ich lieber nach bevor ich es falsch mache und von vorne anfangen muss.
Was ist daran Fatal nachzufragen? Wozu googeln wenn man bereits an der Quelle ist, da sollte es ja vermerkt sein, war es ja auch, nur ein wenig versteckt.
2.
Nachdem ich's fand editierte ich meine Eigene Aussage damit darauf keiner reagieren brauch.
3.
Verallgemeinert, wenn Du mir helfen magst dann bitte hilf ansonsten lass es doch einfach bleiben, das führt zu nichts.

*Winke-Winke LaLa*

[mensch72]

neben dem Henne/Ei Problem ala "Fragen/Suchen/Finden/Wissen" von mir noch folgendes


FB ist wenn es um echte komplette SQL Funktionalität geht sicher eine gute Lösung.
Mit IBexpert gibt es da hier im Forum Support, wenn man (s)einen FB Server auch "richtig" schnell bekommen will/muss.

ABER:
0,5..1M+ Records "schnell" mal "öffnen", "suchen/selektieren", "Daten auslesen/abfragen", "schließen"... da sind die echten SQL Datenbanken auch lokal oft einfach nicht optimal genutzt.


So Vergleiche mache ich abundzu für unser sagen wir "Finanzdatenbackend" mit zugegeben etwas größeren Datensatzmengen (5Mio..5+Mrd) aber im Endeffekt gleicher Aufgabenstellung(existiert schon für DatenpunktXY eine passende errechnete&hinterlegte "Übersichtsmatrix", wenn ja schnell anzeigen, wenn nein eventuell errechnen&zugeordnet sichern).
Echte simple FileIndex-Systeme sind einfach schneller wie alle mir bekannten universellen SQL basierten Sachen FBembedded, SQlite, MSaccess, MSsql(Express,Workgroup,Ent,DatacenterArray).


Daher setzen wir für echte Highspeed Anwendungen weiter auf ein eigenes verteiltes MultipleRead/SingleWrite-StorrageArray.
Ansonsten für solche einfache "Local" 1..8 User Systeme sparen wir uns den eigenen Aufwand, und nutzen ein Zukauftool. (Letztendlich eine "SingleFileEngine", welche Single/Multiuser, Compress/Crypto und SimpleIndex/SQLselect sauber und wirklich schnell selbst löst)
Gute SQL Server haben in schlechten Netzwerken erst ab sagen wir 6 parallelen HiSpeed-Zugriffen Vorteile, in guten Netzwerken merken wir erst ab 10 parallelen HiSpeed-Zugriffen Vorteile bei sehr guten Last verteilen SQL Servern.

http://www.componentace.com/bde_repl...e_database.htm
Da der Test und die private Anwendung kostenlos ist, hindert dich nix das mal mit der sicher guten Kombi aus z.B. IBexpert und FB zu vergleichen.
Solltest du zusätzlich noch Zeit haben, probiere mal UniDac speziell mit einem MSsql-WorkgroupServer... die erreichen per native API unglaublich gute "Connect,Open,Query,Fetch,Close,Disconnect" Zeiten. (ob dir UNIdac mit MultiDB Flexibilität aber ohne MultiPlattform(willst ja nur Windows) das Geld wert ist, das musst selbst wissen)


Anbei noch ein Beispiel, wohin die Methode "DB is unnötig, FileSystem tuts auch" führen kann... da speichert z.B. ein Mitbewerber von uns einfach seine Daten in einer Datei pro Stunde... klingt zunächst nicht weiter aufregend, nur wenn dies über Jahrzehnte und zig Werte geschieht, hat man plötzlich fast 5Mio einzelne Dateien... und da zerlegt es dann so langsam einige 32Bit Windowsprogramme und auch die NTFS Funktionen von Win64 im Explorer und Zwischenablage werden mit sowas arg strapaziert... und wenn da da jeweils auch noch mehr wie 1000Datensätze anfallen braucht es auch eine DB/Logik die mit mehr wie 4Mrd(>2^32) Records umgehen kann