Salut tlm,
 
Voilà, je sais parfaitement à quoi servent les types Tiny/Medium/Long/Blob de MySQL et donc je ne suis pas là pour vous demander comment enregistrer un fichier en binaire dans un de ces champs, pour ça y'a pas de problème.
 
La question qui me trotte dans la tête c'est : à quel moment est-il judicieux de stocker des données (et quels types de données en particulier ?) dans ces champs, que ce soit pour un site web ou un intranet ??
 
Merci d'avance pour vos réponses !
Lionel.

dans le cas de fichiers, on stocke plutôt leur path dans un champ CHAR ou VARCHAR plutôt que le contenu lui-même. Ca va faire grossir inutilement ta BD.

Merci, je le sais parfaitement...  
 
Je repose donc ma question : quel est l'intérêt de stocker des fichiers directement en base (avec tous les inconvénients que ça comporte) plutôt que sur un serveur en stockant uniquement les paths et noms de fichiers en base ?!

là, comme ça, je vois pas

certains avancent comme argument la sécurité. En effet, seule l'appli et le dbmaster aura accès à la base. Perso je trouve pas trop cet argument valable, il suffit de mettre des bons droits sur les fichiers mais voilà déjà une piste

 
"il suffit", mais ça ajoute un truc de plus à faire et à vérifier, vu l'importance de l'erreur humaine dans la sécurité, l'argument peut rester valable.

je vois surtout deux raisons :
 
- déploiment qui est simplifié.
dans le cas d'un site web, t'as un répertoire sécurisé, peut-être totalement en dehors du site, même sur un autre serveur. diffuser les fichier de façon externe à la base, c'est donc s'exposer à des éventuels problèmes pour retrouver les fichiers si on change de serveur (disque réseau à monter de nouveau, base à mettre à jour pour changer le chemin d'accès, etc.)
 
- sécurité de la gestion
le problème des fichiers stockés sur le disque, c'est que lorsqu'on va supprimer un fichier dans la base, ou en ajouter un, il n'est pas évident d'avoir une garantie que la même action à été effectuée sur le fichier. et l'inverse est tout simplement impossible à garantir.
 
sinon, il y a aussi les possibilités d'indexation du contenu des fichiers. les sgbd offrent des solutions généralement plus poussées que les serveurs de fichiers, notamment parcequ'on peut lier les fichiers à d'autres infos lors des requêtes.
 
enfin, le versioning est aisé avec le sgbd, alors qu'il devient rapidement complexe en utilisant le système de fichier (à cause du point 2)

Il risque pas de morfler profond le DB si on stoque dedans des fichiers qu'on a souvent besoin ?

C'est, amha, le point le plus intéressant. C'est d'ailleurs ce qu'utilisent svn/cvs non ? (j'ai un doute pour le second mais logiquement...)

C'est pas forcément recommandé, et surtout, un travail de DBA est nécessaire (notamment pour gérer proprement où sont stockées les infos des blob). Mais en soit, c'est fait pour. Par contre, si je me base sur la doc de SQL Server par exemple, l'association blob + fulltext, ils proposent... une machine 10 fois suppérieure à la config recommandée
"Un quadri-processeur, avec 1 à 2 Go de mémoire par processeur, et au moins deux chaines RAID 5 (chaînes RAID 50 recommandées)", alors que c'est tiré de la doc de SQL Server 2000, qui s'accomodait parfaitement d'un petit serveur mono-proc à 400 MHz, une simple chaîne RAID 5 et de 1 ou 2 Go de mémoire pour la config recommandée
 
Bon, après tout dépend de la charge, du tuyaux qu'il y a entre l'application et le SGBD et la propreté du code (genre on évite les "select *" histoire de ne pas rammener les valeurs des blob quand on n'en a pas besoin)

C'est clair que si on balance des select * à toutes les sauces alors que le gamin du chef de projet a trouvé cool d'uploader toutes ses video

 
Moi j'utilise les BLOB pour controler l'accès à certains fichiers.
Exemple une page web qui permet d'uploader des images qui ne peuvent être visibles que par celui qui les a uploadées ou une liste de membres.
 
C'est un truc tout con et ca me parait bizarre que personne ici n'a mentionné cette utilisation.
 
Je ne vois aucune autre solution aussi facile

Tu obtiens rigoureusement le même comportement en ne stockant que le path et en gérant proprement l'affichage des images...
 

=> Comme tu peux le voir, là l'image ne se charge pas. Pourquoi ? Parceque tu n'es pas authentifié sur le site d'où ça viens et que tu n'as pas accepté la charte de lecture des images.
Pourtant, elles sont stockées sur le disque ces images, et pas dans la base. TU peux toujours courrir pour les afficher sans authentification.
 
(lol, merde, je tombe juste sur un mauvais exemple, j'ai ouvert les portes quand la requête vient d'HFR )

 
(ah, voilà, c'est l'affichage en grand qui est bloqué ^^)
 
tout ça pour dire qu'il n'y a pas la trace du moindre blob dans ma base, et qu'il y a une gestion de droits...

Ah.
 
Et ca permet donc de spécifier quel utilisateur peut la voir ? Jusqu'à quel niveau de précision (pour tout les membres loggués, pour un membre loggué en particulier, etc.) ?  
 
Comment tu fais pour dire que tel utilisateur peut acceder à telle image mais pas à une autre ?
 
Ca marche par cookies ?

Actuellement, le niveau de protection est faible :
- Tous les membres logués
- A condition qu'ils aient accepté un message d'infos légal pour certaines images
 
Mais je peux pousser aussi loin que je veux.
Le système est le même en fait :
- les images sont dans un répertoire en dehors du site
- une page "image.asp" effectue un certain nombre de contrôles via la BDD avant de décider si j'affiche l'image ou une image de remplacement tel qu'ici
- cette page "image.asp" retourne le contenu du fichier retenu, avec un content-type qui correspond au format de l'image au lieu du format html
- dans mon cas, j'utilise trois types de variables (en plus de la base de données) : session -pour vérifier que l'utilisateur est authentifié-, cookie -pour vérifier qu'il a accepté les mentions légales-, et server (pour vérifier que la demande vient d'un site authorisé à afficher les images)
=> du coup, j'utilise un bête tah "<img src="image.asp"/>" pour afficher l'image de mon choix, et ceci permet de bloquer totalement les requêtes vers des fichiers qui ne sont pas autorisés pour l'utilisateur