Dateisystem vs. Datenbanken?
Hallo,
Mein Prof hat in der Vorlesung erklärt welchen Nachteil Dateisysteme gegenüber Datenbanken haben. Ein Punkt war, dass "die physikalische Struktur der Datenorganisation bekannt sein muss. Das führt zu unflexiblen Anwendungsprogrammen". Für mich ist das aber zu kryptisch.
Blickt jemand durch, was er genau damit gemeint hat?
Danke
7 Antworten
Äpfel vs. Tomaten? Mein Prof hat erklärt, dass Tomaten den Nachteil haben, knallrot zu sein.
So ungefähr liest sich das. Dateisysteme und Datenbanken haben grundsätzlich unterschiedliche Ansätze mit Vor- und Nachteilen. Meine Bilder speichere ich selbstverständlich in einem Dateisystem. Ich habe allerdings auch eine Bildverwaltung, in der die Metadaten der Bilder verwaltet werden. Das geschieht in einer Datenbank. Die Bilder in einer Datenbank abzulegen, wäre ziemlich unsinnig. Schließlich liegt die Datenbank auch in einem Dateisystem, ich würde um die Bilder also quasi nur noch einen Umschlag legen, der nicht benötigt wird. Die Metadaten der Bilder haben eine Struktur, z. B. Dateiname, Dateipfad, Aufnahmedatum, Belichtungsdaten, Kamera, Brennweite, GPS-Daten, Stichwörter. Das sind strukturierte Daten, die man wunderbar in einer Datenbank verwalten kann. So kann man schnell ein bestimmtes Bild finden, was im Dateisystem anhand des Dateinamens kaum möglich ist.
Es gibt halt Dinge, die man mit einem Dateisystem nicht lösen kann. Andere Dinge kann man mit einer Datenbank nicht lösen.
Ich glaube diese Aussage ist einfach plain falsch.
Grund: Dateisysteme sind ebenfalls Abstraktionsschichten, die die physikalische Speicherung auf dem Datenträger komplett verstecken.
Man kann also höchstens sagen, dass die Art der Abstraktion und meinetwegen die Granularität eine andere ist.
Wenn man z.B. Binärdaten in einer DB speichert hat man gegenüber einem Dateisystem nichts gewonnen, sondern nur zusätzlichen Verwaltungsaufwand eingeführt.
Es geht hier um den vergleich eines Dateisystems oder einer datenbank zur ablage von daten.
Im ersteren Falle werden die Daten natürlich im dateisystem abgelegt. Wie es z.b. bei Spielen und saves etc. oft der fall ist. Oder mit Konfigurationseinstellungen.
Für die Datenorganisation muss man dann zwangsläufig das dateisystem kennen.
Ich Denke wir interpretieren die "physialische Struktur der Datenorganisation anders" Ich Interpretiere es eher in dem Sinne das man eben direkt mit dem dateisystem arbeitet. Und nicht mit einer DB. Aber nicht im sinne das ich daten direkt auf irgendwelchen Plattensektoren etc. Ablege.
Aber durchaus fakt ist das ich mit ner DB vollkommen unabhängig vom Dateisystem bin.
Nur dass das eben in die eigene Tasche gelogen ist.
Speicher die Savegames in die DB, dann brauchst du Zugangsdaten und musst die Tabellenstruktur kennen.
Ein FS ist einfach simpler zu adressieren (Pfadname identifiziert ein Datum) und für Binärdaten ausgelegt (was in der Datei steht ist deine Sache, ist dem FS nahezu egal).
Und, wenn wir mal ehrlich sind: Die DB wird heutzutage auch meisten auf einem FS installiert... die Tabellen sind am Ende einfach wieder Dateien.
Speicher die Savegames in die DB, dann brauchst du Zugangsdaten und musst die Tabellenstruktur kennen.
Ja natürlich. Die Sind doch aber betriebsystem unabhängig. Ich denke das der lehrer genau darauf hinauswollte.
Mein Prof hat in der Vorlesung erklärt welchen Nachteil Dateisysteme gegenüber Datenbanken haben.
Hier. Das ist im endeffekt Pro und Contra zu DB und Dateisystem.
die physikalische Struktur der Datenorganisation bekannt sein muss.
Ist demnach ein Contra argument gegen dateisystem und für Datenbanken. Entsprechend befinden wir uns in einem Kontext der abwägung von Filesystem und DB zum ablegen von Daten. Auf der ebene eines Software entwicklers.
Die DB wird heutzutage auch meisten auf einem FS installiert... die Tabellen sind am Ende einfach wieder Dateien.
Und das hier z.b. ist imgrunde vollkommen irrelevant. Weil es den entwickler der die DB benutzt nicht die Bohne interessiert wo und wie diese Installiert ist. Also aus sicht der anwendungsentwicklung.
"Die physikalische Struktur der Datenorganisation" muss bei einem FS aber immer noch nicht bekannt sein. In der Praxis ist sie es auch gar nicht.
Die Dateien liegen irgendwo zerstückelt auf einem Massenspeicher, bei einer SSD völlig anders als bei einer rotierenden Festplatte. Die physikalische Ablage ist völlig irrelevant, nur die logische Organisation (in Ordner etc.) ist in irgendeiner Weise von Belang.
Sich in eine vom Betriebssystem oder/und Benutzer vorgegebene Ordnerstruktur einzufügen ist qualitativ nichts anderes, als sich in eine Tabellenstruktur einer DB einzuordnen: Man muss es richtig machen, sonst tut es nicht (oder macht sogar Dinge kaputt).
Eine neu aufgesetzte DB ist genauso leer und unstrukturiert wie ein frisch formatiertes FS.
Es gibt sicherlich Pro- und Contra-Argumente, aber die "physikalische Datenorganisation" ist gerade kein solches. Die ist nämlich vor dem Anwendungsprogramm gänzlich versteckt.
Es gibt sicherlich Pro- und Contra-Argumente, aber die "physikalische Datenorganisation" ist gerade kein solches. Die ist nämlich vor dem Anwendungsprogramm gänzlich versteckt.
Da hast du recht. Ich habe den Begriff "physikalische Datenorganisation" schlichtweg anders interpretiert. Daher die Konfusion.
Hi,
Im einer Datenbank, kannst du über Schlüssel oder andere Möglichkeit die Daten aus meheren Tabellen usw direkt verknüpfen und das kann man ja zb mit sql automatisch machen.
Oder nimm die room database für Android, da kannste ellenlange arrays reinwerfen und ausholen.
Wenn du uber die order gehst, musst du halt immer wissen wo was ist. Und wenn neue Dateien dazu kommen musst du das ja auch irgendwie bewerkstelligen, dass du die dann wieder findest. Dann bräuchte man warscheinlich ne Datenbank wo die Dateiennamen und Pfade drin stehn😅
Dein Professor hat recht:
In einer Datenbank abgespeichert zu sein (d.h. durch ein DBMS verwaltet zu werden) erspart dem Ersteller deines Programms, diese Verwaltung selbst konzipieren und implementieren zu müssen.
Sie selbst zu implementieren wäre ziemlich aufwändig für den Fall, dass auf die Daten zahlreiche Anwendungsprozesse gleichzeitig — in Konkurrenz zu einander — Zugriff haben sollen.
Wenn ich ne DB habe, habe ich die Betriebsystemunabhängig. Sagen wir ich habe ne SQL Server datenbank. Und ich verbinde mich per Netzwerkpfad auf diese.
Dann kann ich mit dem selben code daten dort ablegen egal wo diese installiert ist. Sie könnte auf meinem System sein. Auf einem Windows Server. oder einem Linux Server. oder auf einem Toaster.
Das Dateisystem wird durch die Datenbank Abstrahiert. Ich arbeite nur mit Tabellen und dem was SQL Server mit halt bietet an funktionalität.
Wenn ich jedoch direkt mit einem Dateisystem arbeite dann kann sich dieses Dateisystem von Betriebsystem zu betriebsystem unterscheiden. Guter vergleich sind hier windows und Linux. Die ihre ordner etc. Ganz anders anordnen und Linux z.b. keine laufwerksbuchstaben kennt. Oder umgebungsvariable ganz anders sind.
Wenn man nun noch abgefahre Dateisystem nimmt die eventuell gar keine Ordner haben können. Oder bei denen Pfade anders angegeben werden. Dann wird das zu enormen problemen führen wenn man damit arbeiten will. Dann muss man sich als programmierer ersteinmal damit auskennen und 2. wissen auf welchen dateisystem das Programm überhaupt läuft. (Also wenn das Programm ausgeführt wird)
Das ist denke ich damit gemeint.
Ist sie nicht. Probiere mal auf linux was zum laufen zu bringen welches die dinge nach C programe Speichern will. XD