Quand un fichier n’est-il qu’un fichier ?

Question

Ainsi, vous écrivez une application Web et vous disposez de plusieurs zones du site où l'utilisateur peut télécharger des fichiers.Ma méthode de travail de base pour cela consiste à stocker le fichier réel sur le serveur et à disposer d'une table de base de données qui connecte le nom de fichier stocké à l'enregistrement auquel il se rapporte.

Ma question est la suivante :Doit-il y avoir un tableau différent pour chaque « type » de fichier ?De plus, les fichiers doivent-ils être stockés dans des emplacements liés au contexte sur le serveur, ou tous ensemble ?

Quelques exemples:photos de profil utilisateur, CV de candidature, documents associés sur les pages CMS, etc.

Answer 1

D'après votre exemple, il existe un argument pour deux tables, car vous avez des fichiers qui peuvent être associés à deux choses différentes.

• Les CV, photos sont associés à un utilisateur.
• les pièces jointes sont associées à une page CMS.

Si vous les mettez dans un seul tableau (et que vous souhaitez autoriser les utilisateurs à avoir plus d'une photo ou un CV), vous avez besoin de deux tables de liens pour associer fichiers->utilisateurs et fichiers->cms_pages.Cela implique sans doute une relation HABTM, qui n'est pas correcte et permet des données incohérentes.

L'approche à deux tables est légèrement plus propre et permet uniquement d'associer les fichiers au type d'entité correct avec une simple relation d'appartenance à.

Mais je ne pense pas qu'il y ait de « bonne » réponse à cette question, à moins que vous n'ayez besoin de stocker différents types de métadonnées pour différents types de fichiers.

Assurez-vous également de stocker ou de pouvoir calculer le type MIME de chaque fichier afin qu'il puisse être renvoyé correctement au navigateur, avec les en-têtes HTTP corrects.

Answer 2

D'après ce que vous avez dit, je stockerais simplement les fichiers avec des noms de fichiers aléatoires (UUID ou autre) au même endroit.J'aurais alors un tableau « pièces jointes » ou quelque chose qui contient des références à tous vos fichiers externes.Ce tableau contiendrait également les métadonnées de ce fichier, donc de quel type de fichier il s'agit (photo, CV, etc.) et ainsi de suite.

Il peut cependant y avoir des limites strictes au nombre de fichiers dans un répertoire, en fonction du FS que vous utilisez.

Answer 3

Il peut y avoir diverses raisons de stocker différents fichiers dans différents emplacements.

Premièrement, une restriction sur le nombre de fichiers dans un répertoire pourrait être une considération.

Deuxièmement, la sécurité peut être un problème : si certains doivent être visibles publiquement (comme les photos de profil par exemple) mais que d'autres ne le sont pas (comme les CV), il serait alors plus facile de les placer dans des répertoires différents.

Troisièmement, les tâches d'administration simples peuvent être plus faciles si les fichiers sont divisés, par exemple en parcourant un explorateur de fichiers, en gérant les sauvegardes ou en modifiant l'application pour diviser le stockage des fichiers sur plusieurs emplacements.

Il existe également un problème de conflits de noms de fichiers, mais si vous renommez tout pour qu'il corresponde au champ d'identification de la base de données (par exemple), cela ne posera pas de problème.

Mais en fin de compte, cela dépend probablement des volumes et de vos propres préférences.

Answer 4

Un tableau différent pour chaque type de fichier ne devient pertinent que si vous stockez d'autres métadonnées (et donc des colonnes supplémentaires) pour chaque type de fichier.Si vos tables pour chaque type de fichier contiennent uniquement les mêmes colonnes (par exemple, nom de fichier, type de fichier, date de téléchargement, etc.), il serait alors logique de les avoir toutes sur une seule table.