Meilleure façon de stocker les fichiers téléchargés par les utilisateurs dans une application Web

Question

Je crée une application Web (dans Django), qui doit permettre aux utilisateurs de télécharger des fichiers (en particulier des images, qui sont ensuite affichées pour d'autres utilisateurs). J'essaie de comprendre la meilleure façon de stocker ces fichiers téléchargés. Des questions connexes, j'ai vu certaines personnes suggérées de donner au fichier un identifiant unqiue généré par le serveur, puis de créer une table DB qui mappe les identifiants aux noms de fichiers d'origine.

Est-ce la meilleure approche pour stocker des fichiers téléchargés par les utilisateurs, d'un point de vue sécurité, efficacité ou tout autre point de vue? Quel genre d'informations dois-je stocker sur chaque fichier?

Existe-t-il d'autres pratiques recommandées pour accepter les fichiers téléchargés par l'utilisateur? (À part s'assurer qu'il s'agit bien d'images et de vérifier leur taille, évidemment)?

Modifier: Un peu plus d'informations sur ce dont j'ai besoin. Je parle spécifiquement des fichiers image que les utilisateurs doivent télécharger et intégrer dans le contenu qu'ils créent. Imaginez-vous comme une réponse StackOverflow (ou un article de blog): quelqu'un télécharge une image, qui doit être stockée et affichée chaque fois que quelqu'un d'autre voit la réponse.

Merci,
Edan
Note: Il y a plusieurs questions connexes, mais je n'ai pas trouvé un qui demande une comparaison des façons de stocker les fichiers téléchargés par l'utilisateur.

Answer 1

C'est une grande question.

En relation avec votre cas d'utilisation d'image, il s'agit du domaine d'un serveur d'image qui est généralement une partie distincte de l'application. Ils gèrent le cycle de vie et le redimensionnement des images (une image est stockée/redimensionnée à différentes tailles). Pour autant que je l'ai vu, cela n'a jamais été implémenté par une colonne BLOB à partir de SQL, mais par un simple fichier normal sur le disque.

ont également un coup d'oeil à (infrastructure example from facebook)

En général, le produit doit aligner sur vos besoins concrets (taille de fichier, nombre de fichiers, charge). Dans la plupart des cas, vous ne voulez vraiment pas créer tout ça à partir de zéro ... Bien que vos besoins soient moins élevés (quelques utilisateurs téléchargent rarement des fichiers), vous pouvez sauvegarder ces fichiers sur le disque et enregistrer le chemin comme référence dans vos autres données (par exemple, colonne dans SGBDR).

Answer 2

Votre question est trop large pour être vraiment utile; La meilleure approche dépendra de vos besoins spécifiques. Néanmoins ...

Les programmeurs sont constamment tentés de plonquer des fichiers dans la base de données. Résister. Il ajoute juste une couche de complexité à tout ce que vous essayez de faire avec eux par la suite. Pour mon expérience, tout en utilisant un hashkey comme nom de fichier local était ma préférence, cela ne fonctionnait pas vraiment parce que nos fichiers n'étaient pas limités aux images: les non-images ont besoin d'un nom de fichier pour servir aux utilisateurs, et les téléchargeurs n'aiment pas particulièrement que leurs fichiers soient radicalement renommés, car il leur est impossible de savoir quel fichier est quoi. En ce qui concerne les images, il existe un travail non trivial à faire pour redimensionner à différentes tailles/vignettes.