Nicht von Natur aus, aber wenn Sie große BLOBs haben, die Ihre Tabellen und Ihren Speichercache verstopfen, wird dies sicherlich zu Leistungseinbußen führen.
Ja, das ist ein gängiger Ansatz. Normalerweise würden Sie so etwas wie Ordner nach jeder Tabelle benennen, mit der sie verknüpft sind, und Dateinamen enthalten, die nur auf dem Primärschlüssel basieren (idealerweise eine Ganzzahl; auf keinen Fall etwas, das vom Benutzer übermittelt wurde).
Ist das eine bessere Idee? Es hängt davon ab, ob. Es gibt Vorteile in Bezug auf die Einfachheit der Bereitstellung, wenn Sie nur einen einzigen Datenspeicher haben und sich keine Gedanken darüber machen müssen, dem Webbenutzer Schreibzugriff auf irgendetwas zu gewähren. Auch wenn möglicherweise mehrere Kopien der App ausgeführt werden (z. B. Aktiv-Aktiv-Lastenausgleich), müssen Sie den Speicher synchronisieren, was mit einer Datenbank viel einfacher ist als mit einem Dateisystem.
Wenn Sie das Dateisystem anstelle eines Blobs verwenden, stellt sich die Frage, ob Sie den Webserver dazu bringen, es zu bedienen, indem Sie einen Alias auf den Ordner verweisen?
- + ist superschnell
- + lässt sich gut zwischenspeichern
- - zusätzliche Serverkonfiguration:virtuelles Verzeichnis; benötigt eine geeignete Dateierweiterung, um den gewünschten
Content-Typezurückzugeben - - zusätzliche Serverkonfiguration:
Content-Disposition: attachmentmuss hinzugefügt werden /X-Content-Type-OptionsHeader, um das IE-Sniffing nach HTML als Teil von Anti-XSS-Maßnahmen zu stoppen
oder stellen Sie die Datei manuell bereit, indem Sie sie von einem serverseitigen Skript ausspucken lassen, wie Sie es von einem MySQL-Blob aus bereitstellen müssten?
- - ist potentiell langsam
- - erfordert einiges an manuellem If-Modified-Since- und ETag-Handling, um richtig zwischenzuspeichern
- + kann anwendungseigene Zugriffskontrollmethoden verwenden
- + Einfaches Hinzufügen korrekter Content-Type- und Content-Disposition-Header aus dem Serving-Skript
Dies ist ein Kompromiss, für den es keine global akzeptierte Antwort gibt.
