Wenn ich Rails verwende, gibt es einen Grund, warum ich Anlagen im Dateisystem speichern sollte (anstatt sie in der Datenbank zu speichern). Die Datenbank scheint mir einfacher zu sein, Sie müssen sich keine Gedanken über Dateisystempfade, Struktur usw. machen, sondern schauen einfach in Ihr Blob-Feld. Aber die meisten Leute scheinen das Dateisystem zu benutzen, das lässt mich raten, dass es einige Vorteile geben muss, damit ich nicht komme, oder einige Nachteile, wenn ich die Datenbank für diesen Speicher verwende. (In diesem Fall verwende ich postgres).
Dies ist eine ziemlich standardmäßige Designfrage und es gibt nicht wirklich eine "eine wahre Antwort".
Die Faustregel, der ich normalerweise folge, ist "Daten gehen in Datenbanken, Dateien gehen in Dateien".
Einige der zu beachtenden Punkte:
Wenn eine Datei in der Datenbank gespeichert ist, wie werden Sie sie über HTTP bereitstellen? Denken Sie daran, dass Sie den Inhaltstyp, den Dateinamen usw. festlegen müssen. Wenn es sich um eine Datei im Dateisystem handelt, kümmert sich der Webserver um all diese Dinge für Sie. Sehr schnell und effizient (vielleicht sogar im Kernel-Bereich) wird kein interpretierter Code benötigt.
Dateien sind normalerweise groß. Große Datenbanken sind sicherlich machbar, aber sie sind langsam und unpraktisch zu sichern usw. Warum sollten Sie Ihre Datenbank groß machen, wenn Sie nicht müssen?
Ähnlich wie 2. ist es sehr einfach, Dateien auf mehrere Maschinen zu kopieren. Angenommen, Sie führen einen Cluster aus, können Sie das Dateisystem von Ihrem Master-Rechner regelmäßig zu Ihren Slaves synchronisieren und die statische HTTP-Server-Bereitstellung verwenden. Offensichtlich können Datenbanken auch gruppiert werden, es ist einfach nicht so intuitiv.
Auf der anderen Seite von 3, wenn Sie Ihre Datenbank bereits gruppieren, ist die administrative Komplexität zusätzlich mit gruppierten Dateien zu bewältigen. Dies wäre ein Grund, über die Speicherung von Dateien in der Datenbank nachzudenken, würde ich sagen.
Blobdaten in Datenbanken sind normalerweise undurchsichtig. Sie können es nicht filtern, sortieren oder gruppieren. Das verringert den Wert der Speicherung in der Datenbank.
Auf der anderen Seite verstehen Datenbanken Nebenläufigkeit. Sie können Ihr Standardmodell für die Transaktionsisolation verwenden, um sicherzustellen, dass zwei Clients nicht versuchen, dieselbe Datei gleichzeitig zu bearbeiten. Das könnte nett sein. Um nicht zu sagen, dass Sie Lockfiles nicht verwenden könnten, aber jetzt haben Sie zwei Dinge zu verstehen, anstatt eines.
Zugänglichkeit. Dateien in einem Dateisystem können mit normalen Werkzeugen geöffnet werden. Vi, Photoshop, Word, was immer Sie brauchen. Dies kann bequem sein. Wie öffnest du dieses Word-Dokument aus einem Blob-Feld?
Berechtigungen. Dateisysteme haben Berechtigungen, und sie können im Nachhinein schmerzhaft sein. Umgekehrt könnten sie für Ihre Anwendung nützlich sein. Berechtigungen werden Sie wirklich beißen, wenn Sie 7 nutzen, weil es fast garantiert ist, dass Ihr Webserver mit anderen Berechtigungen als Ihre Anwendungen ausgeführt wird.
Cache (von Sarah mei unten). Dies spielt die HTTP-Frage oben auf der Client-Seite ab (werden Sie daran denken, Lebensdauern richtig einzustellen?). Auf der Serverseite sind Dateien auf einem Dateisystem ein sehr gut verstandenes und optimiertes Zugriffsmuster. Große Blob-Felder können von Ihrer Datenbank optimiert werden oder auch nicht, und es ist fast garantiert, dass ein zusätzlicher Netzwerk-Trip von der Datenbank zum Webserver stattfindet.
Kurz gesagt, Leute neigen dazu, Dateisysteme für Dateien zu verwenden, weil sie Datei-ähnliche Idiome am besten unterstützen. Es gibt keinen Grund, dies zu tun, und Dateisysteme werden mehr und mehr zu Datenbanken, so dass es mich nicht überraschen würde, irgendwann eine vollständige Konvergenz zu sehen.
Es gibt einige gute Ratschläge für die Verwendung des Dateisystems für Dateien, aber hier ist noch etwas zu überlegen. Wenn Sie vertrauliche oder sichere Dateien / Anhänge speichern, ist die Verwendung der Datenbank wirklich die einzige Möglichkeit. Ich habe Apps entwickelt, bei denen die Daten nicht in einer Datei ausgegeben werden können. Es muss aus Sicherheitsgründen in die DB eingegeben werden. Sie können es nicht in einem Dateisystem für einen Benutzer auf dem Server / der Maschine belassen, um sie ohne geeignete Sicherheit anzuschauen oder mitzunehmen. Mit einer erstklassigen Datenbank wie Oracle können Sie diese Daten sehr genau sperren und sicherstellen, dass nur geeignete Benutzer auf diese Daten zugreifen können.
Aber die anderen Punkte sind sehr gültig. Wenn Sie nur Dinge wie Avatarbilder oder nicht sensible Informationen machen, ist das Dateisystem für die meisten Plugin-Systeme in der Regel schneller und bequemer.
Die DB ist ziemlich einfach einzurichten, um Dateien zurückzusenden; Es ist ein bisschen mehr Arbeit, aber nur ein paar Minuten, wenn Sie wissen, was Sie tun. Also, ja, das Dateisystem ist der bessere Weg, um insgesamt zu gehen, IMO, aber die DB ist die einzig gangbare Wahl, wenn Sicherheit oder sensible Daten ein Hauptanliegen sind.
Ich sehe nicht, was das Problem mit Blobstores ist. Sie können immer einen Dateisystemspeicher daraus rekonstruieren, z. indem das Material während der Verwendung des Systems auf dem lokalen Webserver zwischengespeichert wird. Aber der autoritative Speicher sollte immer die Datenbank sein. Dies bedeutet, dass Sie Ihre Anwendung bereitstellen können, indem Sie in die Datenbank werfen und den Code aus der Quellcodeverwaltung exportieren. Erledigt. Und das Hinzufügen eines Webservers ist überhaupt kein Problem.
Wenn Sie ein Plugin wie Paperclip verwenden, müssen Sie sich auch um nichts kümmern. Es gibt dieses Ding namens Dateisystem, wo Dateien gehen sollten. Nur weil es ein bisschen schwieriger ist, heißt das nicht, dass Sie Ihre Dateien an den falschen Ort bringen sollten. Und mit Büroklammer (oder anderen ähnlichen Plugins) ist es nicht schwer. Also, gogo Dateisystem!
Tags und Links ruby-on-rails