Je travaille sur un grand système logiciel qui a créé les deux mécanismes pour stocker les pièces jointes et d'autres contenus. La première itération du système stockait toutes les données dans des BLOB dans la base de données. Je l'ai maudit à l'époque. En tant que programmeur, je pouvais écrire des scripts annexes pour opérer immédiatement sur les données et les modifier à tout moment.
Avancez d'environ 10 ans et je gère toujours le même logiciel mais l'architecture a changé et il a été écrit avec des pointeurs de système de fichiers. Je le maudis maintenant et j'aimerais qu'il soit de retour dans la DB. J'ai l'avantage supplémentaire de plusieurs années et ayant travaillé cette application avec une capacité beaucoup plus grande dans de nombreuses situations plus nombreuses et plus importantes, je pense que mon opinion est maintenant mieux éduquée. La promotion ou la migration du système de l'application nécessite de nombreux scripts et la copie de millions de fichiers. À une occasion, nous avons changé le système d'exploitation et tous les pointeurs de fichier avaient le mauvais séparateur de répertoire, ou le nom du serveur changeait où se trouvait le fichier et nous avons dû écrire et planifier des instructions de mise à jour SQL simples avec le DBA le week-end pour corriger. Une autre est que les enregistrements du système de fichiers et de la base de données ne sont pas synchronisés, pourquoi est-ce incertain, mais après des milliers de jours de fonctionnement, parfois des systèmes non transactionnels (le système de fichiers et la base de données ne partagent pas les contextes transactionnels) deviennent tout simplement désynchronisés. Parfois, des fichiers disparaissent mystérieusement.
Lorsque tout cela se trouvait dans la base de données, la migration ou la promotion de l'environnement était une question de vidage et d'importation de la base de données. Les modifications de ligne peuvent être correctement auditées, tout est synchronisé et les journaux peuvent être relus à un moment donné si nécessaire. Bien sûr, la base de données devient importante, mais nous sommes en 2011 et ce n'est tout simplement pas un défi pour les bases de données.
Pour ce que cela vaut, nous avons eu des problèmes similaires avec de grands tampons de données lors de la diffusion de certaines données, mais A) nous pouvions pomper les données dans des tampons d'octets avec les Input|OutputStreams dans JDBC et B) lors de l'utilisation d'autres outils, nous avons écrit une procédure stockée cela fragmenterait le BLOB dans une table temporaire et servirait de manière itérative les fragments de la table temporaire. Fonctionne très bien.
Je me fiche de la raison technique de pas mettre ce truc dans la base de données, mais c'est tellement plus facile pour gérer dans un emplacement consolidé, je pourrais doubler et tripler le matériel ou griller la base de données pour le temps perdu par les consultants et les clients en une courte période de temps à gérer les fichiers disparates.
Mise à jour :soyez indulgents avec les commentateurs, ils ne font que donner leur avis sur la question.
