Bilder in der Datenbank speichern – Ja oder Nein?

https://stackoverflow.com/questions/3748

08-06-2019
|

Frage

Ich verwende also eine App, die Bilder stark in der Datenbank speichert.Wie ist Ihre Meinung dazu?Ich bin eher der Typ, den Speicherort im Dateisystem zu speichern, als ihn direkt in der Datenbank zu speichern.

Was sind Ihrer Meinung nach die Vor- und Nachteile?

Keine korrekte Lösung

Andere Tipps

Ich bin für einige Anwendungen verantwortlich, die viele TB an Bildern verwalten.Wir haben diesen Speicher gefunden Dateipfade in der Datenbank, um am besten zu sein.

Es gibt ein paar Probleme:

Datenbankspeicher ist normalerweise teurer als Dateisystemspeicher
Mit handelsüblichen Standardprodukten können Sie den Dateisystemzugriff enorm beschleunigen
- Beispielsweise verwenden viele Webserver das Betriebssystem Datei senden() Systemaufruf zum asynchronen Senden einer Datei direkt vom Dateisystem an die Netzwerkschnittstelle.In einer Datenbank gespeicherte Bilder profitieren nicht von dieser Optimierung.
Dinge wie Webserver usw. benötigen keine spezielle Codierung oder Verarbeitung, um auf Bilder im Dateisystem zuzugreifen
Datenbanken setzen sich durch, wenn die Transaktionsintegrität zwischen Bild und Metadaten wichtig ist.
- Es ist komplexer, die Integrität zwischen Datenbankmetadaten und Dateisystemdaten zu verwalten
- Es ist schwierig (im Kontext einer Webanwendung), sicherzustellen, dass Daten auf die Festplatte im Dateisystem geschrieben wurden

Wie bei den meisten Problemen ist es nicht so einfach, wie es klingt.Es gibt Fälle, in denen es sinnvoll wäre, die Bilder in der Datenbank zu speichern.

Sie speichern Bilder, die sich dynamisch ändern, sagen Sie Rechnungen und wollten eine Rechnung wie am 1. Januar 2007 erhalten?
Die Regierung möchte, dass Sie die 6-jährige Geschichte bewahren
Für in der Datenbank gespeicherte Bilder ist keine andere Sicherungsstrategie erforderlich.Im Dateisystem gespeicherte Bilder tun dies
Es ist einfacher, den Zugriff auf die Bilder zu kontrollieren, wenn sie sich in einer Datenbank befinden.Inaktive Administratoren können auf jeden Ordner auf der Festplatte zugreifen.Es braucht einen wirklich entschlossenen Administrator, der in einer Datenbank herumschnüffelt, um die Bilder zu extrahieren

Andererseits sind damit auch Probleme verbunden

Erfordern Sie zusätzlichen Code zum Extrahieren und Streamen der Bilder
Die Latenz kann langsamer sein als direkte Dateizugriff
Höhere Belastung des Datenbankservers

Dateispeicher.Facebook-Ingenieure hatten einen großartigen Vortrag darüber.Ein Vorteil bestand darin, die praktische Beschränkung der Dateien in einem Verzeichnis zu kennen.

Nadel im Heuhaufen:Effiziente Speicherung von Milliarden Fotos

Das ist vielleicht etwas weit hergeholt, aber wenn Sie SQL Server 2008 verwenden (oder dies planen), würde ich Ihnen empfehlen, einen Blick auf die neue Version zu werfen Datenfluss Datentyp.

FileStream löst die meisten Probleme beim Speichern der Dateien in der Datenbank:

Die Blobs werden tatsächlich als Dateien in einem Ordner gespeichert.
Auf die Blobs kann über zugegriffen werden entweder eine Datenbankverbindung oder über das Dateisystem.
Backups sind integriert.
Migration „funktioniert einfach“.

Die „Transparent Data Encryption“ von SQL verschlüsselt jedoch keine FileStream-Objekte. Wenn dies also eine Überlegung ist, ist es möglicherweise besser, sie einfach als Varbinary zu speichern.

Aus dem MSDN-Artikel:

Transact-SQL-Anweisungen können FILESTREAM-Daten einfügen, aktualisieren, abfragen, durchsuchen und sichern.Win32-Dateisystemschnittstellen ermöglichen den Streaming-Zugriff auf die Daten.
FILESTREAM verwendet den NT-Systemcache zum Zwischenspeichern von Dateidaten.Dies trägt dazu bei, etwaige Auswirkungen von FILESTREAM-Daten auf die Leistung des Datenbankmoduls zu reduzieren.Der SQL Server-Pufferpool wird nicht verwendet.Daher steht dieser Speicher für die Abfrageverarbeitung zur Verfügung.

Dateipfade in der Datenbank sind definitiv Der richtige Weg – ich habe immer wieder von Kunden mit einer TB an Bildern gehört, dass es zu einem Albtraum wurde, eine nennenswerte Menge an Bildern in einer Datenbank zu speichern – allein der Leistungseinbruch ist zu groß.

Meiner Erfahrung nach ist es manchmal die einfachste Lösung Benennen Sie die Bilder entsprechend dem Primärschlüssel.So ist es einfach, das Bild zu finden, das zu einem bestimmten Datensatz gehört, und umgekehrt.Aber gleichzeitig speichern Sie nicht irgendetwas über das Bild in der Datenbank.

Der Trick hier besteht darin, kein Eiferer zu werden.

Hier ist zu beachten, dass niemand im Pro-Dateisystem-Lager ein bestimmtes Dateisystem aufgelistet hat.Bedeutet das, dass alles von FAT16 bis ZFS jede Datenbank deutlich übertrifft?

NEIN.

Die Wahrheit ist, dass viele Datenbanken viele Dateisysteme schlagen, selbst wenn es nur um die reine Geschwindigkeit geht.

Die richtige Vorgehensweise besteht darin, die richtige Entscheidung für Ihr genaues Szenario zu treffen. Dazu benötigen Sie einige Zahlen und einige Anwendungsfallschätzungen.

An Orten, an denen Sie referenzielle Integrität und ACID-Konformität gewährleisten MÜSSEN, ist die Speicherung von Bildern in der Datenbank erforderlich.

Sie können nicht transaktionstechnisch garantieren, dass das Bild und die in der Datenbank gespeicherten Metadaten zu diesem Bild auf dieselbe Datei verweisen.Mit anderen Worten: Es kann nicht garantiert werden, dass die Datei im Dateisystem immer nur gleichzeitig und in derselben Transaktion wie die Metadaten geändert wird.

Wie andere bereits gesagt haben, verfügt SQL 2008 über einen Filestream-Typ, der es Ihnen ermöglicht, einen Dateinamen oder einen Bezeichner als Zeiger in der Datenbank zu speichern und das Bild automatisch in Ihrem Dateisystem zu speichern, was ein großartiges Szenario ist.

Wenn Sie eine ältere Datenbank verwenden, würde ich sagen, dass Sie, wenn Sie sie als Blob-Daten speichern, wirklich nichts in Bezug auf Suchfunktionen aus der Datenbank herausholen werden, also ist es wahrscheinlich das Beste um eine Adresse in einem Dateisystem zu speichern und das Bild auf diese Weise zu speichern.

Auf diese Weise sparen Sie auch Platz in Ihrem Dateisystem, da Sie nur genau so viel Platz oder sogar komprimierten Platz im Dateisystem einsparen.

Sie können sich auch dafür entscheiden, mit einer Struktur oder Elementen zu speichern, die es Ihnen ermöglichen, die Rohbilder in Ihrem Dateisystem ohne Datenbanktreffer zu durchsuchen, oder die Dateien in großen Mengen auf ein anderes System, eine Festplatte, S3 oder ein anderes Szenario zu übertragen – indem Sie den Speicherort aktualisieren Ihr Programm, aber behalten Sie die Struktur bei, auch hier ohne großen Aufwand, wenn Sie versuchen, die Bilder aus Ihrer Datenbank zu entfernen, wenn Sie versuchen, den Speicher zu vergrößern.

Wahrscheinlich wäre es Ihnen auch möglich, ein Caching-Element, basierend auf häufig aufgerufenen Bild-URLs, in Ihre Web-Engine/Ihr Programm einzufügen, sodass Sie sich auch dort sparen.

Kleine statische Bilder (nicht mehr als ein paar MB), die nicht häufig bearbeitet werden, sollten in der Datenbank gespeichert werden.Diese Methode bietet mehrere Vorteile, darunter eine einfachere Portabilität (Bilder werden mit der Datenbank übertragen), eine einfachere Sicherung/Wiederherstellung (Bilder werden mit der Datenbank gesichert) und eine bessere Skalierbarkeit (ein Dateisystemordner mit Tausenden kleiner Miniaturansichtsdateien klingt für mich wie ein Albtraum der Skalierbarkeit). Mich).

Das Bereitstellen von Bildern aus einer Datenbank ist einfach. Implementieren Sie einfach einen HTTP-Handler, der das vom DB-Server zurückgegebene Byte-Array als Binärstream bereitstellt.

Hier ist ein interessantes Whitepaper zu diesem Thema.

BLOB oder nicht BLOB:Große Objektspeicherung in einer Datenbank oder einem Dateisystem

Die Antwort lautet "Es kommt darauf an." Sicherlich würde es vom Datenbankserver und seinem Ansatz zum Speichern von Blob abhängen.Es hängt auch von der Art der in Blobs gespeicherten Daten sowie davon ab, wie auf diese Daten zugegriffen werden soll.

Kleinere Dateien können mithilfe der Datenbank als Speichermechanismus effizient gespeichert und bereitgestellt werden.Größere Dateien werden wahrscheinlich am besten im Dateisystem gespeichert, insbesondere wenn sie häufig geändert/aktualisiert werden.(Blob-Fragmentierung wird zu einem Leistungsproblem.)

Hier ist ein weiterer Punkt, den Sie beachten sollten.Einer der Gründe, die für die Verwendung einer Datenbank zum Speichern der Blobs sprechen, ist die ACID-Konformität.Der von den Testern im Whitepaper verwendete Ansatz (Bulk Logged-Option von SQL Server), der den SQL Server-Durchsatz verdoppelte, änderte jedoch effektiv das „D“ in ACID in ein „d“, da die Blob-Daten nicht mit protokolliert wurden die ersten Schreibvorgänge für die Transaktion.Wenn die vollständige ACID-Konformität eine wichtige Anforderung für Ihr System ist, halbieren Sie daher die SQL Server-Durchsatzzahlen für Datenbankschreibvorgänge, wenn Sie Datei-E/A mit Datenbank-Blob-E/A vergleichen.

Eine Sache, die noch niemand erwähnt hat, die aber auf jeden Fall erwähnenswert ist, ist, dass es auch in den meisten Dateisystemen Probleme im Zusammenhang mit der Speicherung großer Bildmengen gibt.Wenn Sie beispielsweise den oben genannten Ansatz wählen und jede Bilddatei nach dem Primärschlüssel benennen, werden Sie auf den meisten Dateisystemen auf Probleme stoßen, wenn Sie versuchen, alle Bilder in einem großen Verzeichnis abzulegen, sobald Sie eine sehr große Anzahl von Bildern erreicht haben ( z.B.in Hunderttausenden oder Millionen).

Eine gängige Lösung hierfür besteht darin, sie in einen ausgewogenen Baum von Unterverzeichnissen zu hashen.

Was niemand erwähnt hat, ist, dass die Datenbank atomare Aktionen und Transaktionsintegrität garantiert und sich mit Parallelität befasst.Sogar die referenzielle Integrität ist bei einem Dateisystem ausgeschlossen – woher wissen Sie also, dass Ihre Dateinamen wirklich noch korrekt sind?

Was passiert, wenn Sie Ihre Bilder in einem Dateisystem haben und jemand die Datei liest, während Sie eine neue Version schreiben oder die Datei sogar löschen?

Wir verwenden Blobs, weil sie auch einfacher zu verwalten sind (Sicherung, Replikation, Übertragung).Sie funktionieren gut für uns.

Das Problem beim Speichern nur von Dateipfaden zu Bildern in einer Datenbank besteht darin, dass die Integrität der Datenbank nicht mehr erzwungen werden kann.

Wenn das tatsächliche Bild, auf das der Dateipfad verweist, nicht mehr verfügbar ist, weist die Datenbank unbeabsichtigt einen Integritätsfehler auf.

Angesichts der Tatsache, dass es sich bei den Bildern um die eigentlichen Daten handelt, nach denen gesucht wird, und dass sie einfacher in einer integrierten Datenbank verwaltet werden können (die Bilder verschwinden nicht plötzlich), als dass eine Schnittstelle zu einer Art Dateisystem erforderlich ist (wenn auf das Dateisystem unabhängig zugegriffen wird), Wenn die Bilder plötzlich „verschwinden“ könnten, würde ich sie direkt als BLOB oder ähnliches speichern.

In einem Unternehmen, in dem ich früher gearbeitet habe, haben wir 155 Millionen Bilder in einer Oracle 8i (damals 9i)-Datenbank gespeichert.7,5 TB wert.

Normalerweise bin ich strikt dagegen, den teuersten und am schwierigsten zu skalierenden Teil Ihrer Infrastruktur (die Datenbank) zu nehmen und ihm die gesamte Last zu überlassen.Andererseits:Es vereinfacht die Backup-Strategie erheblich, insbesondere wenn Sie über mehrere Webserver verfügen und die Daten irgendwie synchron halten müssen.

Wie die meisten anderen Dinge hängt es von der erwarteten Größe und dem Budget ab.

Wir haben ein Dokument-Imaging-System implementiert, das alle Bilder in SQL2005-Blobfeldern speichert.Im Moment sind es mehrere Hundert GB, und wir sehen hervorragende Reaktionszeiten und kaum oder gar keine Leistungseinbußen.Darüber hinaus verfügen wir zur Einhaltung gesetzlicher Vorschriften über eine Middleware-Schicht, die neu gepostete Dokumente in einem optischen Jukebox-System archiviert, das sie als Standard-NTFS-Dateisystem bereitstellt.

Wir waren mit den Ergebnissen sehr zufrieden, insbesondere im Hinblick auf:

Einfache Replikation und Sicherung
Möglichkeit zur einfachen Implementierung eines Dokumentversionierungssystems

Wenn es sich um eine webbasierte Anwendung handelt, könnte die Speicherung der Bilder in einem Speicherbereitstellungsnetzwerk eines Drittanbieters wie Amazon S3 oder der Nirvanix-Plattform von Vorteil sein.

Annahme:Die Anwendung ist webfähig/webbasiert

Ich bin überrascht, dass das niemand wirklich erwähnt hat ...Delegieren Sie es an andere, die Spezialisten sind -> Verwenden Sie einen Bild-/Datei-Hosting-Anbieter eines Drittanbieters.

Speichern Sie Ihre Dateien bei einem kostenpflichtigen Onlinedienst wie

Ein weiterer StackOverflow-Thread, der darüber spricht Hier.

Dieser Thread erklärt, warum Sie einen Hosting-Anbieter eines Drittanbieters nutzen sollten.

Es ist es so wert.Sie speichern es effizient.Es wird keine Bandbreite von Ihren Servern auf Clientanfragen usw. hochgeladen.

Wenn Sie nicht mit SQL Server 2008 arbeiten und gute Gründe dafür haben, bestimmte Bilddateien in die Datenbank aufzunehmen, können Sie den „beides“-Ansatz wählen und das Dateisystem als temporären Cache und die Datenbank als Master-Repository verwenden .

Ihre Geschäftslogik kann beispielsweise vor der Bereitstellung prüfen, ob eine Bilddatei auf der Festplatte vorhanden ist, und bei Bedarf aus der Datenbank abrufen.Dadurch erhalten Sie die Möglichkeit mehrerer Webserver und weniger Synchronisierungsprobleme.

Ich bin mir nicht sicher, wie sehr das ein Beispiel aus der „realen Welt“ ist, aber ich habe derzeit eine Anwendung, die Details für ein Sammelkartenspiel speichert, einschließlich der Bilder für die Karten.Zugegebenermaßen beträgt die Datensatzanzahl für die Datenbank bisher nur 2851 Datensätze, aber angesichts der Tatsache, dass bestimmte Karten mehrmals veröffentlicht wurden und alternative Illustrationen haben, war es tatsächlich effizienter, das „Primärquadrat“ der Illustration und dann dynamisch zu scannen, was die Größe betrifft Generieren Sie auf Anfrage den Rand und verschiedene Effekte für die Karte.

Der ursprüngliche Ersteller dieser Bildbibliothek hat eine Datenzugriffsklasse erstellt, die das Bild basierend auf der Anfrage rendert und dies für die Anzeige und einzelne Karte recht schnell erledigt.

Dies erleichtert auch die Bereitstellung/Aktualisierung, wenn neue Karten auf den Markt kommen. Anstatt einen ganzen Ordner mit Bildern zu komprimieren und diese durch die Pipeline zu schicken und sicherzustellen, dass die richtige Ordnerstruktur erstellt wird, aktualisiere ich einfach die Datenbank und lasse sie vom Benutzer erneut herunterladen.Derzeit beträgt die Größe bis zu 56 MB, was nicht besonders gut ist, aber ich arbeite an einer inkrementellen Update-Funktion für zukünftige Versionen.Darüber hinaus gibt es eine „Keine Bilder“-Version der Anwendung, die es Benutzern über eine Einwahl ermöglicht, die Anwendung ohne Download-Verzögerung zu erhalten.

Diese Lösung hat bisher hervorragend funktioniert, da die Anwendung selbst als einzelne Instanz auf dem Desktop angestrebt wird.Es gibt eine Website, auf der alle diese Daten für den Online-Zugriff archiviert werden, aber ich würde dafür auf keinen Fall dieselbe Lösung verwenden.Ich stimme zu, dass der Dateizugriff vorzuziehen wäre, da er sich besser an die Häufigkeit und das Volumen der Anfragen für die Bilder anpassen ließe.

Hoffentlich ist das nicht zu viel Geschwätz, aber ich habe das Thema erkannt und wollte einige meiner Erkenntnisse aus einer relativ erfolgreichen kleinen/mittleren Anwendung darlegen.

SQL Server 2008 bietet eine Lösung, die das Beste aus beiden Welten vereint: Der Dateistream-Datentyp.

Verwalten Sie es wie eine normale Tabelle und nutzen Sie die Leistung des Dateisystems.

Dies hängt von der Anzahl der Bilder ab, die Sie speichern möchten, und auch von deren Größe.Ich habe in der Vergangenheit Datenbanken zum Speichern von Bildern verwendet und habe damit recht gute Erfahrungen gemacht.

Meiner Meinung nach sind die Vorteile der Verwendung einer Datenbank zum Speichern von Bildern:

A.Sie benötigen keine FS-Struktur, um Ihre Bilder zu speichern
B.Datenbankindizes sind leistungsfähiger als FS-Bäume, wenn mehr Elemente gespeichert werden sollen
C.Eine intelligent abgestimmte Datenbank leistet gute Arbeit beim Zwischenspeichern der Abfrageergebnisse
D.Backups sind einfach.Es funktioniert auch gut, wenn Sie eine Replikation eingerichtet haben und Inhalte von einem Server in der Nähe des Benutzers bereitgestellt werden.In solchen Fällen ist eine explizite Synchronisierung nicht erforderlich.

Wenn Ihre Bilder klein sein sollen (z. B. < 64 KB) und die Speicher-Engine Ihrer Datenbank Inline-BLOBs (in Datensätzen) unterstützt, verbessert sich die Leistung weiter, da keine Indirektion erforderlich ist (Referenzlokalität wird erreicht).

Das Speichern von Bildern kann eine schlechte Idee sein, wenn Sie mit einer kleinen Anzahl großer Bilder arbeiten.Ein weiteres Problem beim Speichern von Bildern in der Datenbank besteht darin, dass Metadaten wie Erstellungs- und Änderungsdaten von Ihrer Anwendung verarbeitet werden müssen.

Ich habe kürzlich eine PHP/MySQL-App erstellt, die PDFs/Word-Dateien in einer MySQL-Tabelle speichert (bisher bis zu 40 MB pro Datei).

Vorteile:

Hochgeladene Dateien werden zusammen mit allem anderen auf den Backup-Server repliziert, es ist keine separate Backup-Strategie erforderlich (Sicherheit).
Das Einrichten des Webservers ist etwas einfacher, da ich keinen Uploads/-Ordner haben und nicht allen meinen Anwendungen mitteilen muss, wo er sich befindet.
Ich kann Transaktionen für Bearbeitungen verwenden, um die Datenintegrität zu verbessern – ich muss mir keine Sorgen über verwaiste und fehlende Dateien machen

Nachteile:

mysqldump dauert jetzt sehr lange, da eine der Tabellen 500 MB Dateidaten enthält.
Insgesamt nicht sehr speicher-/cpueffizient im Vergleich zum Dateisystem

Ich würde meine Implementierung als Erfolg bezeichnen, sie kümmert sich um die Backup-Anforderungen und vereinfacht das Layout des Projekts.Die Leistung ist für die 20-30 Personen, die die App nutzen, in Ordnung.

Meiner Erfahrung nach musste ich beide Situationen bewältigen:In der Datenbank gespeicherte Bilder und Bilder im Dateisystem mit in der Datenbank gespeichertem Pfad.

Die erste Lösung, Bilder in der Datenbank, ist etwas „sauberer“, da Ihre Datenzugriffsschicht nur mit Datenbankobjekten umgehen muss;Aber das ist nur dann gut, wenn Sie mit niedrigen Zahlen zu tun haben.

Offensichtlich nimmt die Leistung des Datenbankzugriffs ab, wenn Sie mit binären großen Objekten arbeiten, und die Datenbankdimensionen nehmen stark zu, was wiederum zu Leistungseinbußen führt ...und normalerweise ist Datenbankspeicherplatz viel teurer als Dateisystemspeicherplatz.

Andererseits führt die Speicherung großer Binärobjekte im Dateisystem dazu, dass Sie Backup-Pläne haben, die sowohl die Datenbank als auch das Dateisystem berücksichtigen müssen, und das kann bei manchen Systemen ein Problem darstellen.

Ein weiterer Grund, sich für ein Dateisystem zu entscheiden, besteht darin, dass Sie Ihre Bilddaten (oder Töne, Videos usw.) für den Zugriff Dritter freigeben müssen:Derzeit entwickle ich eine Web-App, die Bilder verwendet, auf die von „außerhalb“ meiner Webfarm zugegriffen werden muss, sodass ein Datenbankzugriff zum Abrufen von Binärdaten schlichtweg unmöglich ist.Manchmal sind es also auch Designüberlegungen, die Sie zu einer Wahl veranlassen.

Berücksichtigen Sie bei dieser Auswahl auch, ob Sie sich beim Zugriff auf Binärobjekte mit Berechtigungen und Authentifizierung befassen müssen:Diese Anforderungen können normalerweise einfacher gelöst werden, wenn die Daten in der Datenbank gespeichert werden.

Ich habe einmal an einer Bildverarbeitungsanwendung gearbeitet.Wir haben die hochgeladenen Bilder in einem Verzeichnis gespeichert, das etwa /images/[heutiges Datum]/[ID-Nummer] lautete.Wir haben aber auch die Metadaten (Exif-Daten) aus den Bildern extrahiert und diese zusammen mit einem Zeitstempel und dergleichen in der Datenbank gespeichert.

In einem früheren Projekt habe ich Bilder im Dateisystem gespeichert, und das verursachte große Probleme mit Backups, Replikation und der Synchronisierung des Dateisystems mit der Datenbank.

In meinem neuesten Projekt speichere ich Bilder in der Datenbank und speichere sie im Dateisystem zwischen, und es funktioniert wirklich gut.Ich hatte bisher keine Probleme.

Zweitens die Empfehlung zu Dateipfaden.Ich habe an einigen Projekten gearbeitet, bei denen es um die Verwaltung umfangreicher Asset-Sammlungen ging, und alle Versuche, Dinge direkt in der Datenbank zu speichern, führten langfristig zu Schmerzen und Frustration.

Der einzige wirkliche „Vorteil“, der mir in Bezug auf die Speicherung in der Datenbank einfällt, ist die Möglichkeit, einzelne Bild-Assets einfach zu speichern.Wenn keine zu verwendenden Dateipfade vorhanden sind und alle Bilder direkt aus der Datenbank gestreamt werden, besteht keine Gefahr, dass ein Benutzer Dateien findet, auf die er keinen Zugriff haben sollte.

Das scheint jedoch besser mit einem zwischengeschalteten Skript gelöst zu werden, das Daten aus einem über das Internet nicht zugänglichen Dateispeicher abruft.Der DB-Speicher ist also nicht WIRKLICH notwendig.

Es heißt, dass es keine sehr gute Idee ist, es sei denn, Sie sind ein Datenbankanbieter, der beweisen möchte, dass Ihre Datenbank dazu in der Lage ist (z. B. Microsoft prahlt damit, dass Terraserver eine Bajillion Bilder in SQL Server speichert).Wenn die Alternative – das Speichern von Bildern auf Dateiservern und Pfaden in der Datenbank – so viel einfacher ist, warum sollte man sich dann die Mühe machen?Blob-Felder ähneln in gewisser Weise den Geländefähigkeiten von SUVs – die meisten Menschen nutzen sie nicht, diejenigen, die sie nutzen, geraten normalerweise in Schwierigkeiten, und dann gibt es diejenigen, die dies tun, aber nur aus Spaß an der Freude.

Das Speichern eines Bildes in der Datenbank bedeutet immer noch, dass die Bilddaten irgendwo im Dateisystem landen, aber unkenntlich gemacht werden, sodass Sie nicht direkt darauf zugreifen können.

+ves:

Datenbankintegrität
Es ist einfach zu verwalten, da Sie sich nicht darum kümmern müssen, das Dateisystem synchron zu halten, wenn ein Bild hinzugefügt oder gelöscht wird

-ves:

Leistungseinbußen – eine Datenbanksuche ist normalerweise langsamer als eine Dateisystemsuche
Sie können das Bild nicht direkt bearbeiten (Zuschneiden, Größe ändern)

Beide Methoden sind weit verbreitet und praktiziert.Schauen Sie sich die Vor- und Nachteile an.In jedem Fall müssen Sie darüber nachdenken, wie Sie die Nachteile überwinden können.Das Speichern in einer Datenbank bedeutet normalerweise, Datenbankparameter zu optimieren und eine Art Caching zu implementieren.Wenn Sie ein Dateisystem verwenden, müssen Sie eine Möglichkeit finden, Dateisystem und Datenbank synchron zu halten.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow