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.