Warum ist nicht MySQL Blob empfohlen

Question

Ich denke daran, ein kleines Magazin, das ich online zeigen möchte zusammenstellen, und dachte, dass eine gute Möglichkeit wäre, eine Tabelle bestehend aus einer ID-Nummer plus Blob zu haben Daten, um jede Seite als Bild anzuzeigen.

Also, wenn ich ein Problem hatte der 10-Seite aus, würde es wie folgt aussehen:

ID . Page_1_Blob . Page_2_Blob . Page_3_Blob . Page_4_Blob . Page_5_Blob . etc 

Sache ist, dass ich eine Menge von Negativität gesehen haben, wenn es für Bilder Blob-Daten zu speichern kommt, genauer gesagt aufgrund der Tatsache, dass es Ihre Datenbank verlangsamt? Wie wahr ist das? Und gibt es Argumente für die Verwendung von Blob-Daten auf diese Weise?

Answer 1

Also mein Verständnis davon ist, dass das BLOB in der eigentlichen Datenbankdatei gespeichert wird. Wenn Sie also ein 10-GB-Magazin haben, würden die 10 GB in der eigentlichen SQL-Datenbankdatei landen. Die Datei wird beim Ausführen einer Abfrage in den RAM geladen. Offensichtlich ist das Durchsuchen einer 10-MB-Datei viel schneller als das Laden und Durchsuchen einer 10-GB-Datei. Die Antwort darauf besteht darin, einen SqlFilestream zum Speichern von Informationen in der tatsächlichen Dateistruktur des Servers zu verwenden. Dies führt jedoch zu allen Arten von Ballaches, da die SqlFilestream-API nur auf dem tatsächlichen Computer und nicht auf einem entfernten Computer funktioniert. Für meine Datenbank musste ich ein WCF-Programm einrichten, um meiner Datenbank riesige Dateien hinzuzufügen.

Wenn Sie nur eine Datenbank von etwa 10 Seiten haben, dann sollten Sie auf jeden Fall ein BLOB einstecken. Wenn Sie jedoch ein Magazin nach dem anderen hinzufügen, führt dies zu einer Verlangsamung.

Wenn Sie versuchen, Abfragen wie "Select * from magazines" auszuführen, dauern diese Abfragen ewig, da sie die Binärdaten von diesem Server als Teil der Abfrage zurückgibt. Wenn Sie diese Art von Abfrage in einem Video ausführen, warten Sie lange.