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

[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

[Schokohase]

Zitat von mensch72:

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

Und mit einer DB wäre das Problem nicht da?

Es liegt hier nicht am Ablageort, sondern an der generellen Umsetzung.