Pas en soi, mais si vous avez de gros BLOBs encombrant vos tables et votre cache mémoire, cela entraînera certainement une baisse des performances.
Oui, c'est une approche courante. Vous feriez généralement quelque chose comme avoir des dossiers nommés d'après chaque table à laquelle ils sont associés, contenant des noms de fichiers basés uniquement sur la clé primaire (idéalement un entier ; certainement jamais rien soumis par l'utilisateur).
Est-ce une meilleure idée ? Ça dépend. Il existe des avantages de simplicité de déploiement à n'avoir qu'un seul magasin de données et à ne pas avoir à se soucier de donner à l'utilisateur Web un accès en écriture à quoi que ce soit. De plus, s'il peut y avoir plusieurs copies de l'application en cours d'exécution (par exemple, l'équilibrage de charge actif-actif), vous devez synchroniser le stockage, ce qui est beaucoup plus facile avec une base de données qu'avec un système de fichiers.
Si vous utilisez le système de fichiers plutôt qu'un blob, la question est alors, faites-vous en sorte que le serveur Web le serve en pointant un alias vers le dossier ?
- + est super rapide
- + se cache bien
- - configuration de serveur supplémentaire :répertoire virtuel ; a besoin de l'extension de fichier appropriée pour renvoyer le
Content-Typesouhaité - - configuration de serveur supplémentaire :besoin d'ajouter
Content-Disposition: attachment/X-Content-Type-Optionsen-têtes pour empêcher IE de détecter le HTML dans le cadre des mesures anti-XSS
ou servez-vous le fichier manuellement en le crachant par un script côté serveur, comme vous auriez à le faire à partir d'un blob MySQL ?
- - est potentiellement lent
- - nécessite un peu de manipulation manuelle de If-Modified-Since et ETag pour mettre correctement en cache
- + peut utiliser les propres méthodes de contrôle d'accès de l'application
- + facile d'ajouter les en-têtes Content-Type et Content-Disposition corrects à partir du script de diffusion
Il s'agit d'un compromis pour lequel il n'y a pas de réponse universellement acceptée.
