Hi zusammen

Was spricht dagegen, eine Datenbank (zB. SQLite) auf einem externen Laufwerk anzulegen?

Wer meine Threads etwas verfolgt hat, weiss, dass ich für meine Bilderdatenbank aktuell MySQL verwende. Doch schon seit geraumer Zeit liebäugele ich damit, dafür SQLite einzusetzen, da meine Anwendung grundsätzlich keine Multiuserfähige DB benötigt.

Da die Anwendung Daten für eine Webseite erstellen soll, ist es erstmal egal, mit welchem DBMS sie das tut, weshalb sich meines Erachtens SQLite geradezu aufdrängt.

Nach Erstellung der Daten sollen diese allerdings zu einer Webserveranwendung, welche dann unter MySQL läuft, exportiert werden. Wie ich das bewerkstellige, weiss ich zur Zeit noch nicht detailliert, aber ich denke da schonmal an Datasnap; wie auch immer: das ist hier nicht Teil meiner Frage.

Die ist viel mehr:
Aufgrund des jetztigen DB-Modells soll unter SQLite mindestens eine neuue Datenbank erstellt werden.
Die jetzige DB umfasst

• Felder für NEF-Dateien (Rohdatenformat aus der Kamera), Grösse aktuell 10 -24 MB.
• Felder für BMP-Dateien ("Bearbeitungsformat"), im Schnitt gut 3mal so gross, wie die NEF-Bilder, und zu guter letzt:
• Felderfür Jpegs. Deren Grösse ist letztlich Webseitenverträglich(Grösste Seitenlänge etwa 1200px).
• Dazu kommen künftig noch Felder für Videodateien.

Meine Sammlung umfasst zur Zeit gute 13'000 Bilder im NEF-Format und wird natürlich weiter anwachsen.Zusammen mit bereits "von Hand" erstellten Bitmaps und Jpegs sowie einigen Videos füllen die Dinger mittlerweile eine 1-Terabyte-Disk. Grund genug, anzunehmen, dass die 2TB meiner DB-Disk (Intern) nicht allzulange vorhalten werden...

Die Lösung sehe ich darin, für die verschiedenen benötigten Formate jeweils eine eigene DB zu erstellen, und jede dieser separaten DB's muss sich auf einem beliebigen, auch externen, Laufwerk befinden.
Da aber gerade MySQL voraussetz, dass sich alle seine Daten im selben Verzeichnis befinden (es gibt, zumindest in der Community-Version nur ein DataDir), bin ich nicht sicher, ob mein Vorhaben (mehrere DBs auf verschiedenen externen Laufwerken) so ohne weiteres umsetzbar ist.

Ich hoffe, die Zielsetzung genügend gut beschrieben zu haben und freue mich auf eure Kommentare!

Gruss
Delbor

SQLite ist nicht gut geeignet, große Dateninhalte zu speichern, die Performance geht dann massiv in die Knie. Zumindest war das vor einigen Jahren noch so der Fall. Also falls du die Bilder IN der Datenbank speicher willst, ist SQLite wohl keine so gute Wahl.

https://sqlite.org/intern-v-extern-blob.html

Hmm..

Zitat von Delbor:

• Felder für NEF-Dateien (Rohdatenformat aus der Kamera), Grösse aktuell 10 -24 MB.
• Felder für BMP-Dateien ("Bearbeitungsformat"), im Schnitt gut 3mal so gross, wie die NEF-Bilder, und zu guter letzt:
• Felderfür Jpegs. Deren Grösse ist letztlich Webseitenverträglich(Grösste Seitenlänge etwa 1200px).
• Dazu kommen künftig noch Felder für Videodateien.

Meine Sammlung umfasst zur Zeit gute 13'000 Bilder im NEF-Format und

Puh..
Das sind Datenmengen..

Da dein Programm eigentlich wie ein DMS funktioniert und mit kein DMS bekannt ist, welches so große Dateien in seine DB speichert, solltest Du Dir vielleicht überlegen die Dateien nicht mehr in die DB zu packen, sondern extern und nur eine Verlinkung mit Tags und Co in der DB zu speichern.

Dann kannst Du auch SQLite verwenden..

Zusätzlich würdest Du auch dann noch an die Bilder kommen, wenn sich dein Datenbank-File auf der Externen HD aufgrund einer Engergie-Sparoption verabschiedet

Zitat von bra:

SQLite ist nicht gut geeignet, große Dateninhalte zu speichern, die Performance geht dann massiv in die Knie.

Kann ich bestätigen.
Als wir eine alternative zu ADS Local Server gesucht hatten wurde auch SQLite getestet.
Keine Fehler gefunden was SQL-Abfragen betrifft, aber die Performance war unter alle Kanone.

Weiterhin spricht dagegen, das dies ein unausagekräftiger Thread-Titel ist.


Edit: Damit ich nicht nur mecker: Bei dem was du dann in die DB packen willst, wäre vllt. eine NoSQL Datenbank mal ein ganz anderer Ansatz?

Solange SQLite lokal als Singleuser läuft, gehts auch bei mir mit der Performance (ok..hab nur einige 100 GB Daten).

Da das ganze ins Web soll, würd ich, wie Jumpy schon hingewiesen hat, auf eine NoSQL-Datebank setzten (evtl. mit Elastic Search als Engine). Das kommt recht sicher mit sehr großen Datenmengen klar und bietet den Vorteil skalibar zu sein (Build in).

D.h. sollte in DB-Server nicht mehr ausreichen, hängst du einfach einen zweiten rein und das System kümmert sich darum, woher der Datensatz kommt.

Ich habe den Titel mal angepasst.

Zitat:

Was spricht dagegen, eine Datenbank (zB. SQLite) auf einem externen Laufwerk anzulegen?

Nichts solange Du das lokal machst. Sobald die Daten Teil eines Ganzen sind mußt Du in diesem System mindestens die Abfrage haben od die Daten vorhanden sind und falls Nein wie das System damit umgehen soll. Ich halte ein USB-Laufwerk als Datenspeicher in diesem Zusammenhang für eine Bastellösung, über ein HotswapLW kann man vllt. diskutieren, aber wenn Du wirklich eine Webseite füttern willst, dann sollten Deine Stichworte Raid und ggf. SSD lauten.
Ichg habe vor vielen Jahren eine Abteilungsdatenbank mit externen (SCSI)Laufwerken betrieben, das willst Du Dir nicht ernsthaft antun.

Gruß
K-H

Zitat von Delbor:

Was spricht dagegen, eine Datenbank (zB. SQLite) auf einem externen Laufwerk anzulegen?

Wer meine Threads etwas verfolgt hat, weiss, dass ich für meine Bilderdatenbank aktuell MySQL verwende. Doch schon seit geraumer Zeit liebäugele ich damit, dafür SQLite einzusetzen, da meine Anwendung grundsätzlich keine Multiuserfähige DB benötigt.

Die Lösung sehe ich darin, für die verschiedenen benötigten Formate jeweils eine eigene DB zu erstellen, und jede dieser separaten DB's muss sich auf einem beliebigen, auch externen, Laufwerk befinden.
Da aber gerade MySQL voraussetz, dass sich alle seine Daten im selben Verzeichnis befinden (es gibt, zumindest in der Community-Version nur ein DataDir), bin ich nicht sicher, ob mein Vorhaben (mehrere DBs auf verschiedenen externen Laufwerken) so ohne weiteres umsetzbar ist.

Also bei SQLite spricht nichts gegen ein externes Laufwerk. Außer dass man die mal versehentlich abklemmt und das auch eine SQLite DB vielleicht nicht überlebt (ähnlich wie ein FileCopy in einer laufenden mySQL Instance schwerlich funktioniert)
Erinnere ich mich richtig, dass Du mit der mySQL DB "Schwierigkeiten" hattest, nachdem Du Dateien im laufenden Betrieb kopiert hast?

Falls ja oder auch falls ich mich vertue:
Ich krieg bei solchen Fragen leichtes Magenzwicken. (Der Thread mit der defekten mySQL DB steckt mir wahrscheinlich noch irgendwo quer)

Ich kann verstehen, wenn Du mit SQLite Komplexität abbauen willst gegenüber mySQL. Aber ich habe Zweifel, ob Du da richtig dran gehst.

zuerst: Auch wenn SQLite nur noch eine Datei ist, sowas gehört allenfalls als Backup oder vielleicht in Form eines Netzlaufwerks nicht auf eine lokale Platte.
Wie DB auf Verbindungsabbrüche, Schreibstörungen, .. reagieren kann man in dem erwähnten Thread nachlesen. Das gilt auch für DB, die nur aus einer Datei bestehen.
Dass Du fehlende Multiuserzugriffe anführst, zeigt ja, dass Du Dir Gedanken gemacht hast, aber wenn es um meine eigenen Daten geht und davon noch Terrabyte, würde ich mir recht viele Gedanken machen.

zweitens: gleichförmige Daten in verschiedene Tabellen oder sogar Datenbanken zu speichern ist möglich, aber erhöht den Programmier / Adminaufwand unnötig. Es muss halt alles 2x, 3x, 5x gemacht werden und im Zweifel muss es sogar noch konsistent sein.

drittens: wenn man Daten in diesem Volumen bewegt, will man das gar nicht monolitisch in einer Datei haben. Auslesen und Befüllen, Hoch- Runterladen will man in bequemen Häppchen machen, asynchron, internet / Bandbreitenfreundlich

4tens
"Da aber gerade MySQL voraussetz, dass sich alle seine Daten im selben Verzeichnis befinden .."
Vergiß diese Gedanken einfach, fast jedes RDBMS, dass mehr als eine Datei benötigt (also nicht SQLite, sondern alles was größer ist), erwartet einen Dateizugriff nach klaren Regeln. Die sollte man einhalten.
Datentransport erfolgt demnach per Backup/Restore, Export/Import, ..
Also egal wieviel Dateien und wo sie liegen und was (scheinbar) an oder aus ist, Datenbankdateien werden nicht kopiert, ob by mySQL oder anderswo (Ausnahmen habe ich genannt und sollten nur gemacht werden, wenn die Doku zweifelfreie Wege beschreibt, das zu tun)

Zu Deiner Frage: Für die Datenverwaltung ausschließlich mit gespeicherten Links (Basispfade + relative + Dateinamen) zu arbeiten wurde ja schon vorgeschlagen. Das scheint mir hier ein brauchbarer Ansatz, weil Zitat "kein Multiuserzugriff". Du musst also die Inhalte nicht besonders schützen (vor multiplen Usern) und kannst vermutlich bei Fehlbedienung oder Störung auch persönlich eingreifen und korrigieren.
Wenn Du mit solchen Links arbeitest, ist es dennoch sinnvoll, die Ziele der Links, Deine Dateien vor ungewollten Änderungen zu schützen.

Zitat:

... fast jedes RDBMS, dass mehr als eine Datei benötigt (also nicht SQLite, sondern alles was größer ist ...

Wobei die Anzahl der Dateien eines RDBMS ja nichts über es aussagt