Discussion :

[mallsoul]

Bonjour,

Je veux créer une base de données pour enregistrer des fichiers tels que les fichiers word, pdf, html, etc.

Autrement dit je veux créer une application pour stocker les fichiers de mon PC dans l'objectif de retrouver facilement un fichier quand je vais lancer une recherche à partir d'un mot clé par exemple.

Merci de m'aider.

[Nicolas Esprit]

Bonjour,

Tu peux faire cela avec la plupart, si ce n'est tous les SGBD (SQL Server, Oracle, MySQL).

Et il existes maints tutos, articles ou posts sur ce forum évoquant cela.

[CinePhil]

C'est le plus souvent une mauvaise idée de stocker des fichiers dans une BDD. Il vaut mieux y enregistrer le chemin vers le fichier et laisser le fichier sur le disque.

[Nicolas Esprit]

C'est le plus souvent une mauvaise idée de stocker des fichiers dans une BDD. Il vaut mieux y enregistrer le chemin vers le fichier et laisser le fichier sur le disque.

L'article de SQLPro est intéressant. D'un autre côté si on regarde SharePoint, tous les documents sont stockés en base et pourtant les performances sont là.

De plus il faut distinguer le stockage de fichier texte, dans lesquels on peut être amené à faire des recherches, et effectivement comme l'indique SQLPro : le stockage d'images pour lesquelles on ne fera pratiquement jamais de requête sur le contenu.

Enfin bon, je ne suis pas expert en base de données

[CinePhil]

Dans d'autres messages récents, SQLPro parle de la possibilité offerte par certains SGBD récents de gérer eux-mêmes les fichiers dont ils enregistrent le chemin d'accès.

Les fichiers en questions ne peuvent être enregistrés et mis à jour que via le SGBD

[SQLpro]

Effectivement la méthode de stockage optimale (d'ailleur utilisé par sharepoint en SQL 2008) est génériquement le DATALINK (IBM DB2 par exemple) qui se traduit par FILESTREAM dans MS SQL Server.

A +

[CinePhil]

Effectivement la méthode de stockage optimale (d'ailleur utilisé par sharepoint en SQL 2008) est génériquement le DATALINK (IBM DB2 par exemple) qui se traduit par FILESTREAM dans MS SQL Server.

A +

Ce qui veut dire, si je comprends bien, ne connaissant pas SharePoint, que ce qu'a dit
Nicolas Esprit est faux :

D'un autre côté si on regarde SharePoint, tous les documents sont stockés en base et pourtant les performances sont là.

Dans SharePoint les fichiers ne sont pas "stockés en base" mais gérés par la BDD.

[Nicolas Esprit]

Dans SharePoint les fichiers ne sont pas "stockés en base" mais gérés par la BDD.

J'aurais appris quelque chose aujourd'hui

Mais, à vrai dire, je n'ai jamais fait du SharePoint

[SQLpro]

Tout dépend la version de SQL Server : 2005 en base, 2008 en FILESTREAM.

A +

[batri9]

voila la solution
http://www.ac-creteil.fr/util/progra...pts/upload.php

[StringBuilder]

Bonjour,

Je vous propose en pièce jointe une mini GED que j'ai écrit pour le fun.

Elle est très loin d'être complète.

Elle utilise C# et SQL Server, avec notamment FileStream.
Je me suis même amusé à faire un filtre OCR pour Windows Search, histoire de pouvoir indexer les textes contenus dans les images qu'on voudrait indexer (j'avoue que je m'emmerdais grave ^^)

J'en profite pour vous demander si vous avez le temps de regarder un peu comment j'ai implémenté le bignou pour me dire si j'ai utilisé les fonctionnalités de SQL Server comme il se doit.

Le but de l'application, c'est de scanner des dossiers, recopier en base tous les documents trouvés, et les indexer pour faire des recherches fulltext dessus.

Ca m'a bien amusé quelques heures, mais c'est loin d'être terminé.

Je fourni le programme pour exemple "as this".
Si tu veux le reprendre et le continuer, libre à toi.

Si tu veux t'en inspirer, libre à toi.

Si t'as pas envie de voir comment ça marche, ça te regarde

A la base, j'ai créé cette application uniquement parceque sous Windows XP (que j'ai au boulot) le moteur de recherche est complètement pourri, et je voulais bénéficier du même moteur que sous Vista/7, qui est présent dans SQL Server 2008 aussi.

[SQLpro]

Et oui le couplage Full Text + FileStream de Microsoft SQL Server est super efficace pour une GED....

A +

[nathieb]

Bonjour,

Pas tout a fait d'accord avec le stockage externe.
On a crée (j'ai ...) une application de gestion de documents (images, son vidéo, fichier) ou tout est géré par la base de donnée sous forme de BLOB. Cette base utilise Intermedia d'Oracle, le gros avantage a été la migration 9i vers 11G, un dump et pas de problème de synchro de fichiers. car c'est la base qui gère. d'ailleurs le versionning des Fichiers peut être pris en compte dans la base.

Cela permet d'avoir tout a portée de main, et surtout d'utiliser des mécanismes internes à la base
Recherche Full Text
Comparaison d'images (et oui, c'est possible, sur la couleur, forme etc , bluffant...)
Extraction des méta données des fichiers
Et pas de dialogue entre l'admin réseau et sgbd pour savoir ou sont les fichiers, et s'ils sont disponibles et synchro (ou disparus en cas de panne, si si déjà vécu). L'application devient complètement découplée du SGBD.

Cela fait 4 ans que cela tourne, rien perdu, sauf des fichiers avec le format CLOB.

D'ailleurs il manque un package postgres pour une telle gestion ...
Se pose la question du stockage et de sa taille dans le temps.
De même que l'obsolescence de certains types de fichiers ... et oui, doc en docx ....
J'avoue le Blob c'est assez magique.

Olivier

[StringBuilder]

Bonjour,

Quand on parle de "stockage externalisé", on parle de mécanismes comment "FILESTREAM" de SQL Server.

Il ne s'agit pas d'un stockage externe au SGBD, ni même à la base de données.

Il s'agit simplement de stocker, au niveau de la base de données, les données "blob" dans un espace dédié, directement sur le disque.

Cela ne change en rien :
- les mécanismes de sauvegarde (ces données seront présentes dans le dump)
- les mécanismes d'indexation

En revanche, cela allège :
- la charge des disques : on peut stocker les données FILESTREAM sur un disque dédié, afin de ne pas surcharger les disques dédiés aux données, aux index, aux journaux des transactions, etc.
- de réduire la fragmentation des fichiers de données : un BLOB pouvant être très volumineux, le stocker dans un fichier de la base risque de provoquer régulièrement une croissance du fichier, et ainsi le fragmenter sur le disque. Avec FILESTREAM, chaque blob est stocké sous forme d'un fichier, et donc ne vient pas fragmenter les fichiers de données

[SQLpro]

et puis surtout, les fichiers restant à l'état de fichiers, les performances sont meilleurs du fait que l'on peut :

• choisir un accès par dataset ou bien en flux direct de fichier
• ne pas avoir à "reconstituer" le fichier du côté client car il est déjà stocké en tant que fichier.

Microsoft a publié un benchmark sur le sujet. En dessous de 1 Mo de fichiers, il est préférable de passer la par le dataset au dessus, par un accès direct.

A +

[bastien31000]

Microsoft a publié un benchmark sur le sujet. En dessous de 1 Mo de fichiers, il est préférable de passer la par le dataset au dessus, par un accès direct.

Je tombe sur cette discussion en me posant la question d'héberger les documents de mes clients en base, ce qui aurait l'avantage pour moi des backups plus simples et une gestion de la sécurité plus simple aussi. Les exports données de mes clients peuvent aussi être simplifiés non ?

Je gère des fichiers images de 0 à 1Mo on va dire ainsi que des fichiers pdf ou word ou excel, de 0 à 5 ou 5Mo.

Si je comprends bien la dernière phrase du post précédent, dans mon cas (mysql), il vaut mieux que je continue à stocker le nom du fichier en base et pas le fichier complet dans un blob.

Si les requêtes sont optimisées pour les recherches, notamment en ayant le blob dans une table liée à la table principale (par exemple, une table mes_fichiers et une table mes_fichiers_blob où j'aurai l'id de mon fichier avec le blob associé), ce ne suffirait pas à garantir des performances correctes coté mysql tout en bénéficiant du stockage en base ?

Je sais qu'aucune solution n'est miraculeuse et qu'il y a du bon dans les deux. Et c'est associé à chaque cas. Voilà, pourquoi j'aimerais un avis plus expert sur ma problématique.

Merci d'avance !
Bastien

[StringBuilder]

Dans la discussion, on a surtout parlé de la solution de Microsoft consistant à stocker sous forme de FileStream.

Je ne pense pas que MySQL supporte un équivalent à ce mode de stockage.
Et ce qui s'applique (en termes de performances) à SQL Server n'est de toute façon pas forcément vrai pour MySQL.

En revanche, stocker dans des BLOB est, à mon sens, dans tous les cas la solution la plus pertinante, car cela permet :
- de simplifier les mécanismes de sauvegarde
- de simplifier les mécanismes de sécurité (un fichier est directement lié à des informations dans la table, correspondant à un document particulier, un utilisateur, etc. Ca me semble mieux qu'un fichier "anonyme" sur le disque, qui pourrait être écrasé ou chargé accidentellement en cas de doublon sur le nom par exemple)
- de simplifier les mécanismes de versionning
- de simplifier les mécanismes d'indexation, recherche, etc.

Le côté performances, dans tous les cas, sera, dans la plupart des cas (on va partir du principe que t'as moins de 1 million de documents à gérer) sera pour ainsi dire négligeable (quand bien même un BLOB mettrait 2 fois plus de temps à charger ou 2 fois moins de temps à charger qu'une lecture directe sur le disque) la différence d'à peine quelques milli-secondes est-elle vraiment significative ?

[bastien31000]

Merci pour la réponse.

J'ai bien compris que vous discutiez de la fonctionnalité filestream de sql server et que ce n'était pas disponible avec mysql.

Coté sécurité, je te rejoins aussi complètement.

Sachant cela, je me demandais justement si stocker en base des documents comme les miens (niveau taille) étaient une bonne solution, notamment coté performance. N'étant pas un expert bases de données, je n'ai pas vraiment de notions en terme de performance et de l'impact que ça peut avoir.

En effet, même si je n'ai pas 1 millions de documents, mais disons 1000 documents pour commencer et même 10000, avec une moyenne de 1Mo par doc, on arrive à une base de 10000Mo soit 10Go. Les données représentent 1% de la base et le binaire 99%.

Une base de 10, 20 ou 50 Go, dont 99% en binaire, cela est facile à gérer avec mysql en terme de perf ? (sur un serveur dédié)

J'ajoute que je ne suis en effet pas à qq millisecondes, ni meme centiemes !

Je me dis que ça serait beaucoup plus simple pour moi de gérer tout en base. Mon architecture logicielle est déjà prévu pour car je récupère les documents et images à partir d'une fonction et non pas d'une url.

Merci pour le retour
Bastien

[StringBuilder]

Pour des informations spécifiques à MySQL, je te conseille de t'orienter vers la sous-catégorie dédiée.

J'imagine qu'en mettant les documents sur un fichier de base distinct, les performances globales de la base de données ne devraient pas être spécialement impactées.

Reste à savoir si c'est bien géré avec MySQL et dans quelle mesure c'est possible à mettre en place.

[bastien31000]

ok. Merci. Je vais aller demander aux spécialistes myqsl !

Bonne soirée