Souhaitez-vous stocker des données binaires dans une base de données ou dans un système de fichiers?

Question

C'est une question qui a été posée avant (grande-texte-images-en-sql) mais surtout pour les données qui seront modifiés. Dans mon cas, les données seront stockées et n'a jamais changé. Semble juste raisonnable de maintenir le tout ensemble.

Existe-il des raisons pourquoi je ne devrais pas stocker binaire statique des données dans une base de données?

En supposant qu'il est une chose sensée à faire, quels sont les avantages pour stocker ces données dans des tables distinctes? (Vous pourriez commencer à se rendre compte maintenant que je ne suis pas un DB d'experts...)

Clarifier: Il n'y aura probablement pas plus de 10 à 20 utilisateurs, mais elles seront aux états-unis et au royaume-UNI. Les données binaires devront être transféré en tout cas.

Answer 1

L'avantage de stocker les données dans la base de données est en train de profiter de la DB mécanismes de sécurité et de réduction de coût de maintenance (sauvegardes, ...). L'inconvénient est l'augmentation de DB de la charge et de consommer des connexions (ce qui pourrait être coûteux pour chaque connexion à une licence serveurs de base de données). Si vous utilisez SQL Server 2008, FILESTREAM pourrait être une belle alternative.

Par ailleurs, pour les applications Web (ou d'autres applications qui pourraient avoir besoin de streaming de données), il est généralement plus judicieux de stocker des données en dehors de DB.

Answer 2

Le plus gros inconvénient si vous stockez des BLOBS est la consommation de mémoire. Pouvez-vous imaginer ce que la sélection * de x ferait pour des milliers d'enregistrements avec une image de 45k dans chacun?

Comme Mehrdad l'a dit, il y a aussi des avantages. Donc, si vous décidez de suivre cette approche, vous devez essayer de concevoir votre base de données de sorte que la plupart des requêtes renvoient moins de résultats avec des données BLOB. Peut-être par exemple établir des relations individuelles à cet effet.

Answer 3

Abordant le problème du point de vue des principes, une base de données relationnelle est (principalement) là pour stocker des données structurées. Si vous ne pouvez pas créer une condition de requête ou joindre un élément de données, il n'appartient probablement pas à la base de données. Je ne vois pas d'image BLOB utilisée dans une clause WHERE, donc je dirais de la garder en dehors de la base de données. Un CLOB d'autre part peut être utilisé dans les requêtes.

Answer 4

Je suis familier avec une assez bonne taille OSS projet qui a pris la décision, lors de sa création pour stocker des images dans la base de données MySQL, et il est prouvé pour être dans le top 3 des mauvaises idées, ils ont dû faire face à depuis. (Exacerbée par le fait que le "refactor sans pitié" est une abomination, mais c'est une autre histoire.)

Parmi les graves problèmes que cela a causé:

1. Dépassant maximale efficace de la taille de base de données (mysql). (L'espace total nécessaire pour les images dépasse tous les autres par au moins 2 ordres de grandeur).

2. Les fichiers d'Image perdent leur "fileness". Pas de dates tailles etc. sauf stockées (redondance) que les dates (qui exigent du code de la gestion).

3. Arbitraire séquences d'octets ne traitent pas bien tout le temps, pour le stockage ou la manipulation.

4. "Nous n'aurez jamais besoin d'accéder aux images de l'extérieur" est un dangereux hypothèse.

5. La fragilité. Parce que l'ensemble de l'arrangement n'est pas naturel et délicat, et vous ne savez pas où il va mordre à côté (contribuer à la lutte contre le refactor de mentalité).

Les avantages? Aucun que je peux penser, sauf qu'il pourrait avoir été le chemin de moindre résistance au temps.

Answer 5

Je pense que cela dépend de l'application de votre bâtiment. Si vous êtes à la construction d'un système CMS, et l'utilisation de ces données va être à afficher des images dans un navigateur web, il peut être intéressant d'enregistrer les images sur le disque plutôt que d'être mis dans la base de données. Même si honnêtement, je ferais les deux, ce qui pourrait permettre l'ajout d'un serveur à une batterie sans avoir à copier les fichiers de tous sur la place.

Un autre cas d'utilisation peut être un objet complexe comme un flux de travail, ou même un objet métier avec beaucoup de interdependancies. Vous pourriez sérialiser ces deux en un binaire ou un format de texte, et de les enregistrer dans la base de données. Ensuite, vous obtenez le bénéfice de la DB: ATOMIQUE, Sauvegardes, etc...

Je ne pense pas que les gens devraient être en utilisant select * des requêtes dans la première place. Ce que vous faire est de fournir deux façons de récupérer les données, l'Une des méthodes renvoie les informations de résumé, la deuxième serait de retour la goutte. Je ne peux pas imaginer pourquoi vous auriez besoin de renvoyer des milliers d'images à la fois.