Je souhaite stocker un grand nombre de fichiers sonores dans une base de données, mais je ne sais pas si c'est une bonne pratique. J'aimerais connaître les avantages et les inconvénients de cette façon de procéder.
J'ai également pensé à la possibilité d'avoir des "liens" vers ces fichiers, mais peut-être cela apportera-t-il plus de problèmes que de solutions. Toute expérience dans ce sens sera la bienvenue :)
Note : La base de données sera MySQL.
Tous les systèmes que je connais qui stockent un grand nombre de gros fichiers les stockent en dehors de la base de données. Vous stockez toutes les données interrogeables pour le fichier (titre, artiste, longueur, etc.) dans la base de données, ainsi qu'un chemin partiel vers le fichier. Lorsque le moment est venu de récupérer le fichier, vous extrayez le chemin d'accès au fichier, vous y ajoutez un Racine de fichier (ou une URL) et vous le renvoyez.
Ainsi, vous avez une colonne "localisation", avec un chemin partiel, comme "a/b/c/1000", que vous mettez ensuite en correspondance avec : "http://myserver/files/a/b/c/1000.mp3"
Assurez-vous que vous disposez d'un moyen facile de diriger la base de données des médias vers un autre serveur/répertoire, au cas où vous en auriez besoin pour la récupération des données. Vous pouvez également avoir besoin d'une routine qui re-synchronise la base de données avec le contenu de l'archive de fichiers.
De même, si vous avez des milliers de fichiers multimédias, ne les stockez pas tous dans un répertoire géant, ce qui constitue un goulot d'étranglement sur certains systèmes de fichiers. Divisez-les plutôt en plusieurs sous-arbres équilibrés.
Je pense que les stocker dans la base de données est acceptable, tant que vous utilisez une bonne implémentation. Vous pouvez lire cet ancien mais bon article pour avoir des idées sur la façon d'empêcher les grandes quantités de données dans la base de données d'affecter les performances.
http://www.dreamwerx.net/phpforum/?id=1
J'ai eu littéralement des centaines de gigas chargés dans des bases de données mysql sans aucun problème. La conception et la mise en œuvre sont essentielles, faites-le mal et vous souffrirez.
Autres avantages de la DB (non déjà mentionnés) : - Fonctionne mieux dans un environnement à charge équilibrée - Vous pouvez intégrer plus d'évolutivité au niveau du stockage dorsal.
Avantages de l'utilisation d'une base de données :
Inconvénients de l'utilisation d'une base de données :
Dans le cadre de différents projets, j'ai expérimenté les deux méthodes et nous avons finalement décidé qu'il était plus facile d'utiliser également le système de fichiers. Après tout, le système de fichiers est déjà optimisé pour le stockage, la récupération et l'indexation des fichiers.
Le seul conseil que je pourrais donner à ce sujet est de ne stocker qu'un chemin "Root relatif" vers le fichier dans la base de données, puis de faire en sorte que votre programme ou vos requêtes/procédures stockées/logiciels intermédiaires utilisent un paramètre Root spécifique à l'installation pour récupérer le fichier.
Par exemple, si vous stockez XYZ.Wav dans le répertoire C:\MyProgram\Data\Sounds\X\ le chemin complet serait
C:\MyProgram\Data\Sounds\X\XYZ.WavMais vous stockeriez le chemin d'accès et/ou le nom du fichier dans la base de données comme :
X\XYZ.WavAilleurs, dans la base de données ou dans les fichiers de configuration de votre programme, stockez un chemin racine comme SoundFilePath égal à
C:\MyProgram\Data\Sounds\
Bien sûr, c'est à vous de décider où vous séparez la racine du chemin de la base de données. Ainsi, si vous déplacez l'installation de votre programme, vous n'aurez pas à mettre à jour la base de données.
De plus, s'il doit y avoir lots de fichiers, trouvez un moyen de hacher les chemins afin de ne pas vous retrouver avec un répertoire contenant des centaines ou des milliers de fichiers (dans mon petit exemple, il y a des sous-répertoires basés sur le premier caractère du nom de fichier, mais vous pouvez aller plus loin ou utiliser des hachages aléatoires). Cela rend les indexeurs de recherche heureux également.
Vous pourriez les stocker sous forme de BLOB (ou de LONGBLOB), puis récupérer les données lorsque vous souhaitez accéder aux fichiers multimédias.
ou
Vous pourriez simplement stocker les fichiers multimédias sur un disque et stocker les métadonnées dans la base de données.
Je penche pour cette dernière méthode. Je ne sais pas comment cela se passe dans le monde, mais je soupçonne que beaucoup d'autres personnes feraient de même.
Vous pouvez stocker des liens (chemins partiels vers les données) et ensuite récupérer ces informations. Il est ainsi facile de déplacer les données sur les disques et d'y accéder.
Je stocke le chemin relatif de chaque fichier dans la base de données avec d'autres métadonnées sur les fichiers. Le chemin de base peut ensuite être modifié à la volée si j'ai besoin de déplacer les données réelles vers un autre lecteur (soit local, soit via un chemin UNC).
C'est ainsi que je procède. Je suis sûr que d'autres auront aussi des idées.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
