Des fichiers dans une base de données : un mal absolu ? [Résolu]

[MainMa]

Bonjour.

J'ai eu l'occasion de tomber plusieurs fois sur les discussions sur les forums où une personne demande pour une telle ou telle base de données comment qu'elle doit faire pour y stocker les fichiers, et à la fin il y a toujours une ou plusieurs personnes qui répondent qu'on a pas à stocker les fichiers dans une base de données et qu'il y a le FS pour ça.

Bon, je suis d'accord sur le principe. La base de données n'est pas faite pour y stocker des fichiers. À plus forte raison que c'est souvent plus compliqué, moins performant et souvent plus basique (on va pas implémenter à chaque fois les dates de création/modification, les permissions, etc.).

En revanche, ce que je ne comprend pas, c'est cette opposition inconditionnelle de certains à l'enregistrement des fichiers dans une base de données. Après tout, il existe de très nombreuses hypothèses où je n'ai pas spécialement besoin de passer par l'FS, mais juste d'avoir tout simplement un espace à stocker des blobs.
Du type si j'ai une application web qui permet aux utilisateurs d'envoyer des photos et aux autres de les lire indirectement (càd. l'utilisateur peut les lire seulement s'il est inscrit et connecté, il y a des statistiques à chaque téléchargement, etc., donc ça passe forcement par un code behind qui doit lire et envoyer/streamer le fichier). Dans ce cas, passer par FS n'apporte pas énormément d'avantages, si ce n'est une performance meilleure...

Et aussi, faut dire que la base de données a ses avantages. Unifier toutes les "données dynamiques" (par opposition aux fichiers sources, les binaires, etc.) en un seul endroit permet par exemple de gérer les backups de la base de données uniquement, alors que si j'utilise à la fois la base de données et FS, je dois réfléchir aussi à la gestion des backups des fichiers. D'autre part, la base de données a justement cet avantage de donner une certaine abstraction des mécanismes d'enregistrement des données : à supposer que l'administrateur veut héberger mon application web sur un serveur orienté applications, et la base de données sur un autre orienté données, si l'application utilise l'FS en local, il y aura une perte de performances (et d'une manière générale elle ne sera pas donc adaptée au hardware).

Donc pourquoi cette opposition catégorique ? Qu'est-ce qui m'échappe ?

[ylarvor]

Microsoft a réfléchi à tes problèmatiques de flux dynamique et d'organisation de l'information, il en est sorti le filestream sur sql server 2008.

http://www.microsoft.com/france/visi...f-6481c9a8bcf9

[SQLpro]

relisez ce que j'ai écrit ici : http://sqlpro.developpez.com/cours/stockerimages/ et notamment les commentaires associés. L'article datant d'il y a 10 ans. Depuis la norme de 1999 et certains SGBDR l'ont plus ou moins bien appliqué permet de stocker les fichiers à titre de fichier sous le contrôle du SGBDR. Dans la norme SQL cela s'appelle le DATALINK (exemple DB2) et sous SQL Server c'est le FILESTREAM (équivalent).

Bien entendu il existe des conditions ou, entre le stockage direct, le stockage à titre de DATALINK et enfin le stockage externe, il est plus ou moins intéressant de recourir !

A +

[MainMa]

Envoyé par ylarvor

Microsoft a réfléchi à tes problèmatiques de flux dynamique et d'organisation de l'information, il en est sorti le filestream sur sql server 2008.

http://www.microsoft.com/france/visi...f-6481c9a8bcf9

Oui, enfin, je parlais d'SQL pur, sans FILESTREAM.
En passant, FILESTREAM est recommandé pour les fichiers suffisamment "grands", à savoir, si ma mémoire est bonne, au-delà d'un mégaoctet. Pour l'exemple que j'ai donné, celui des photos des utilisateurs, si on s'attend à des splendides images de 300 Ko en moyenne, je doute que FILESTREAM est la solution la plus adaptée.

Envoyé par SQLpro

relisez ce que j'ai écrit ici : http://sqlpro.developpez.com/cours/stockerimages/ et notamment les commentaires associés. L'article datant d'il y a 10 ans. Depuis la norme de 1999 et certains SGBDR l'ont plus ou moins bien appliqué permet de stocker les fichiers à titre de fichier sous le contrôle du SGBDR. Dans la norme SQL cela s'appelle le DATALINK (exemple DB2) et sous SQL Server c'est le FILESTREAM (équivalent).

Bien entendu il existe des conditions ou, entre le stockage direct, le stockage à titre de DATALINK et enfin le stockage externe, il est plus ou moins intéressant de recourir !

A +

Oui, merci, ça me semble effectivement répondre à ma question.