Question Technique SQL-Server

Bonjour à toutes et à tous,
J'aimerais vous exposer un petit problème, alors voilà je veux stocker des fichiers dans SQL-Server (Blob ou Filestream).
Le problème est qu'on doit pouvoir accéder au fichier via une application que nous ne maîtrisons pas. Je dois maîtriser la localisation du fichier à partir du répertoire de base.

Il me faudrait une petite table de type:

http://img4.hostingpics.net/thumbs/m...071tableau.png

Le but de tous ça étant de localiser les données sur un seul serveur de données (tables et fichiers). Et de transférer les données via SQL-Server.

J'espère avoir été assez explicite sur ce j'attend vos idées.
Cordialement,
Nastro

Citation:

---

Envoyé par Nastro

Le problème est qu'on doit pouvoir accéder au fichier via une application que nous ne maîtrisons pas.

---

Pourquoi vous devez utiliser l'application pour accéder aux fichiers ?

Citation:

---

Envoyé par Nastro

Il me faudrait une petite table de type:
http://img4.hostingpics.net/thumbs/m...071tableau.png
Le but de tous ça étant de localiser les données sur un seul serveur de données (tables et fichiers). Et de transférer les données via SQL-Server.

---

c'est quoi la question ?

Merci de t'intéresser à mon problème :ccool:

Si je comprend bien je n'ai pas été assez clair.
L'application que nous développons permet d'associer à un enregistrement une visualisation (exemple: jpeg,png,dwg,etc...). Aujourd'hui le chemin d'accès aux fichiers est stocké dans l'enregistrement. On veut maintenant stocker le fichier lui-même dans la base de données. Cependant la modification de ces fichiers doit être possible via des applications que nous ne maîtrisons pas.


Quel type d'objet utiliser pour répondre au besoin : Filestream, Blob ? Ou autre que je ne connais pas ?

Citation:

---

Envoyé par Nastro

. On veut maintenant stocker le fichier lui-même dans la base de données.
Quel type d'objet utiliser pour répondre au besoin : Filestream, Blob ? Ou autre que je ne connais pas ?

---

Je ne connais pas l'objectif de votre projet. Mais stocker des images directement dans la base de données ne me paraît pas comme une bonne idée. Lisez ceci

Mais si vous ne pouvez pas/plus changer cette décision, vous pouvez utiliser le type de données VARBINARY(max) . vous n'avez pas indiqué la version de votre SQL Server, les types de données IMAGE et TEXT étant obsolètes !
J'ai montré une méthode pour réaliser cette opération ici

Tout dépend la volumétrie et la taille moyenne de vos fichiers. Cela ne sera à rien de mettre filestream si le jeu n'en vaut pas la chandelle. Par ailleurs, pour utiliser FILESTREAM, il faudra modifier les applications pour qu'elles puissent utiliser cette fonctionnalité. Dans votre cas je ne pense pas que c'est la bonne solution à adopter.

Après vous ne dites pas comment les applications modifient les fichiers ? Sous quelle forme ? Utilisent-elles une API ? Les accès se feront directement dans la base ? Sur le système de fichiers ?

++

Bonjour,

Citation:

---

Envoyé par Zinzinetti

Mais stocker des images directement dans la base de données ne me paraît pas comme une bonne idée. Lisez ceci

---

Certes, mais cet article date de 2006, et entre temps FileStream a été introduit avec SQL Server 2008 et répond à cette problématique.

De par la documentation :

Citation:

---

Si les conditions suivantes sont remplies, vous devez envisager d'utiliser FILESTREAM :

La taille des objets stockés est, en moyenne, supérieure à 1 Mo.

L'accès en lecture rapide est important.

Vous développez des applications qui utilisent une couche intermédiaire pour la logique d'application.

Pour les plus petits objets, le stockage des objets blob varbinary(max) dans la base de données procure souvent de meilleures performances de diffusion en continu.

---

Pour ma part j'ai déjà eu à stocker un grand nombre d'images de petite taille (quelques petits Ko) dans des colonnes de type varbinary(max).
Je n'ai pas constaté de problème particulier, autant à l'utilisation qu'en performances.

Citation:

---

Par ailleurs, pour utiliser FILESTREAM, il faudra modifier les applications pour qu'elles puissent utiliser cette fonctionnalité. Dans votre cas je ne pense pas que c'est la bonne solution à adopter.

---

Je valide.

@++ ;)

Tout d'abord merci pour les réponses.

Avec filestream le fichier est bien stocké dans un dossier du filesystem (super) mais ce fichier si je veux l’éditer via une appli windows (fichier->ouvrir) est impossible car son nom (PathName()) est géré par sql server donc incompréhensible pour l'humain qui veut l’éditer. Ce que je voudrai c'est pouvoir gérer son path a partir du répertoire de base.
Je cherche quelque chose comme ce que fait oracle avec son "create directory"

Je suis donc toujours en galère....

Avec Filestream il va forcément falloir passer par SQL Server ou passer par l'API dediée à cela. L'accès direct aux fichiers n'est pas possible.

Si tu veux pouvoir faire cela il va falloir passer par SQL Server 2012 et les FILETABLE qui permet de faire ce que tu veux. Tu peux attaquer les fichiers et dossiers depuis un système de fichier et gérer les opérations habituelles que tu peux connaître.

++

C’est justement pour répondre à cette demande ou problématique de stockage des fichiers dans la base de données tout en permettant d’y accéder depuis les applications Windows, et ce, sans apporter de modifications, qu’une nouvelle fonctionnalité a été ajoutée dans SQL Server 2012 : FileTable

A partir de SQl Server 2012, il est désormais possible de créer un nouveau type de table appelé FileTable. Un FileTable est mappé à un dossier sur le système de fichiers.

Vous pouvez même accéder à ces dossiers dans l'Explorateur Windows, ou sur le réseau, comme un partage réseau ! vous pouvez même faire glisser et déposer des fichiers dans le dossier FileTable et créer des sous-dossiers.

Quand vous faites cela, un des composants SQL Server intercepte les appels d'API Windows et met à jour le FileTable en conséquence.

Les FileTables s'appuyent sur la fonctionnalité FILESTREAM déjà existante dans SQL Server 2008.

La fonctionnalité FileTable apporte une prise en charge de l'espace de noms de fichier Windows et la compatibilité des applications Windows avec les données de fichier stockées dans SQL Server. FileTable permet à une application d'intégrer ses composants de stockage et de gestion des données, et fournit des services SQL Server intégrés (notamment la recherche sémantique et en texte intégral) sur des données et des métadonnées non structurées.

En d'autres termes, FileTable permet maintenant de stocker des fichiers et des documents dans des tables spéciales dans SQL Server, appelées FileTables, mais d'y accéder à partir d'applications Windows comme si ils avaient été stockés dans le système de fichiers, sans apporter de modifications à vos applications clientes.

Pour plus de détails :
http://msdn.microsoft.com/fr-fr/library/ff929144.aspx

Merci à tous pour vos conseils, je vais me pencher sur la solution du FileTable présent avec SQL Server 2012.

Je vous tiendrais au courant du résultat.

Cordialement,
Nastro

Je confirme la solution FileTable dans SQL Server 2012 est la solution.
Attention plein de contrainte sur la version et la solution (si je ne me trompe pas):
- On peut dire adieu a xp et 2003,
- Pas d'authentification SQL Server
- et tous ce que je ne soupçonne pas...

Merci encore au intervenant.

C'est une solution plus qu'intérressante.

Parmi les limitations
- pas de réplication (pourquoi tant de haine).
- pas de cryptage au niveau de la base.

Par contre je n'ai rien vu concernant l'histoire du XP (je viens de tester l'accès sans aucun soucis).