Re: DigiKam und die alten Bilder
On 04/08/2010 10:51 AM, kai-martin knaak wrote:
> David Raab wrote:
>
>> On 04/07/2010 04:00 AM, kai-martin knaak wrote:
>>> Außerdem ist es ein Beispiel dafür, warum Datenbank-Lösungen mit einem
>>> höheren Admin-Risiko verbunden sind als solche, die mit normalen Dateien
>>> arbeiten.
>> Nö, ist es nicht.
>> Ob nun als Speicherung eine SQLite Datenbank, XML Datei, CSV Datei oder
>> sonstiges genommen wird spielt so keine Rolle. Alles sind Dateien im
>> Dateisysten.
>
> Es gibt allerdings Unterschiede:
Klar gibt es unterschiede. Sonst bräuchte man darüber ja nicht reden.
> Auf eine relationale Datenbank kann nur genau eine Anwendung vernünftig zugreifen.
??? Genau das ist der Vorteil von Relationalen Datenbanken, das eben
mehrere Programme gleichzeitig drauf zugreifen können. Probleme mit
gleichzeitigen zugriff hast du eher bei Dateien. Bzw. hat das nicht mit
Relationale Datenbanken zu tun sondern mit dem verwendeten DBMS.
> Wenn diese Murks macht, ist schnell alles auf einen Schlag hin.
Warum sollte sie murks machen? Wenn du murks mit Dateihandling machst
ist auch schnell alles dahin. Unterschied ist nur das du bei normalen
dateien das handling selber immer wieder von vorne neu programmieren musst.
Ein Beispiel hierfür war übrigens vor nicht all zu langer Zeit KDE4 mit
ext4. Man hatte ext4 einen bug zugeschoben weil die entwickler es nicht
hinbekommen haben dateien korrekt zu speichern. Bei ausfall direkt nach
starten waren dann alle dateien leer gewesen.
Hinweis von Teds Tso war auch das die leute lieber SQLite nehmen sollten
wenn sie mit Dateien nicht umgehen können bzw. es ihnen zu aufwenig ist
es korrekt zu implementieren.
> Wenn die Daten als Sammlung von normalen Dateien im Dateiensystem vorgehalten werden,
> betreffen Fehler zunächst nur die jeweiligen Einzeldateien.
Ich kann auch alles in zig SQLite Datenbanken unterteilen. Besser wird
dadurch auch nichts. Wenn eine Datei von vielen (egal ob nun SQLite,
CSV, XML, ...) defekt ist geht es trotzdem nicht richtig. Zum anderen
erhöht das eventuell die komplexität der Programmierung wenn man alles
in zig dateien aufsplittet oder den Speicherverbrauch. Und das führt
wieder dazu das neue Fehler auftreten.
> Den Rest des Datenbestands kann man dann immer noch normal mit einer älteren
> Version der Anwendung bearbeiten, die den Fehler noch nicht enthält.
Wem seine Daten wichtig sind macht vorher ein Backup. Auch bevor er eine
neue Version einspielt. Die Argumentation das ich eventuell viel
rumfrickeln kann wenn irgendetwas schief geht, finde ich unpassend.
> Außerdem hat man das ganze Arsenal der Mittel zur Sateiorganisation des
> jeweiligen Betriebssystems zur Verfügung, um an der eigentlichen Anwendung
> vorbei auf die Daten zuzugreifen.
Wenn man an der anwendung vorbei auf Daten zugreifen möchte ist sogar
soetwas wie SQLite noch optimaler. SQLite anbindungen gibt es für zig
Programmiersprachen. Hat man normale Dateien muss man übehraupt wissen
wie Dateien abgespeichert werden. CSV, XML. Wie sieht das Schema aus?
Das es XML ist reicht nicht aus wenn ich nicht weiß wie der aufbau von
XML ist und was das Programm erwartet.
SQLite hat einen festen zugriff, das Schema kann ich auslesen.
Und das einzige was ein OS anbietet ist der Umgang mit Dateien, und
nicht mit dem Dateiinhalten. Bei SQLite oder generell Datenbanken wurde
der Umgang davon abstrahiert in einer Bibliothek, anstatt es jede
Anwendung für sich neu implementiert.
> Es gibt erheblich weniger Szenarien, bei denen man als Anwender
> vor einem globalen "Nichts geht mehr" steht.
Das Phänomen "Nichts geht mehr" ist halt nur komplett unabhängig davon
ob man nun eine Datenbank oder ein anderes Format zum Speichern nutzt.
Reply to: