Pour utiliser un blob ou non (mysql + coldfusion)

Question

Je voudrais savoir si le stockage de pdfs dans une table de base de données est une bonne idée à long terme. Voici une description du problème:

J'ai un client qui a des centaines de clients qui téléchargent de nombreux fichiers pdf comme preuves. Ces fichiers pdf vont de très petites (< 100K) à 10MB. Ces fichiers peuvent potentiellement être téléchargés plusieurs fois car ils sont des preuves pour un seul projet (c'est-à-dire proof1.pdf, proof2.pdf etc ..) PDF pour chaque client doit rester séparé, et PDF pour chaque projet doit rester séparé pour chaque client.

Actuellement, il est configuré où les fichiers sont téléchargés directement dans un dossier créé pour chaque client pour chaque projet. C'est OK, mais prend de l'espace et trouver des fichiers peut être un peu un cauchemar. Comme je l'ai dit, plusieurs preuves seront téléchargées pour chaque projet et chaque client.

La meilleure solution à laquelle je puisse penser est de fournir une interface qui téléchargera les fichiers PDF directement dans une table db qui gardera trace de l'identifiant du client, de l'identifiant du projet et de la preuve. Ceci fournit une sécurité bien meilleure et permet d'obtenir tous les fichiers PDF de chaque client pour le projet X.

Un outil de nettoyage de base de données sera développé pour supprimer les enregistrements qui sont plus anciens que la période spécifiée. Ne pas continuer à croître pour toujours, mais je suis inquiet de la performance hit (s'il y en a un) et d'autres points négatifs que je pourrais négliger.

Donc, dans l'ensemble, est-ce une bonne idée ou devrais-je trouver une meilleure façon de gérer cela dans le système de fichiers?

Answer 1

Je recommande le stockage des clés légers qui pointent vers des données dans un système de fichiers, au lieu de stocker les données des fichiers réels dans un champ blob. Une solution possible serait de hacher vos fichiers (avec, disons, SHA-1) et d'utiliser ce hash comme nom de fichier sur le disque - voire d'organiser le stockage dans une arborescence de répertoires sur les premiers caractères de hachage n (ie, 80cdef... peut être stocké dans storage/8/0/c/d/80cdef...).

Votre table peut alors comporter une clé primaire, un nom d'affichage convivial pour le fichier et un champ contenant le nom (hash) du fichier physique sur le disque. Cela vous permet également de séparer physiquement le stockage de fichiers du stockage de la base de données dans, par exemple, un système de fichiers réparti; ce serait une séparation plutôt raisonnable à faire dans un système à long terme qui deviendra inévitablement de très grande taille. De cette façon, vous retenez les avantages d'une base de données relativement petite (potentiellement de meilleures performances et moins de douleurs de sauvegarde) tout en déchargeant le problème plus complexe de stockage massif vers un système existant en dehors de la base de données elle-même. d'approches éprouvées.

Answer 2

J'ai tendance à ne pas stocker de fichiers dans les bases de données. J'ai travaillé avec des installations Blackboard sur un campus et vous pouvez télécharger des fichiers dans cette application. En conséquence, la taille de la base de données est devenue ingérable, dépassant 1 To. Le système de sauvegarde de Blackboard emballait chaque cours sous la forme d'un fichier zip et pour faire une sauvegarde complète d'un cours, tous les fichiers devaient être extraits et compressés ... ceci est devenu un long processus. Nous avons dû scinder (et re-scinder) les sauvegardes régulièrement.

Voici un autre poste qui commente à ce sujet: Stackoverflow post