Discussion :

[Christian_B]

Bonjour,
Je me trouve bloqué dans le choix d'un SGBD et des outils à lui associer (pour créer des bases de données personnelles), par l'absence de livres et la difficulté à trouver des infos sur Internet, sur les moyens les plus simples d'effectuer des opérations banales sur des fichiers externes autres que des SGBD.

Notamment :
- Accès à l'en-tête système des fichiers, pour pouvoir combiner ces données dans la base avec des champs supplémentaires, pour pallier à l'insuffisance des gestionnaires de fichiers, par exemple pour commenter ces fichiers en tenant compte de leur type.
- Ouverture de fichiers de données (dont le chemin est dans la base de données) au moyen de l'application par défaut, comme savent le faire les gestionnaire de fichiers, les navigateurs web ou même certains traitements de texte ... mais pas les SGBD.

Pourquoi par exemple n'existe-t-il pas (à ma connaissance) de champs de type "lien" ou "adresse" (cliquables éventuellement dans un formulaire) ? Et comment pallier simplement à cette absence ?

Je sais qu'il existe de nombreux langages (et peut-être d'autres applis ?) qui permettent de faire cela et bien plus, mais comment s'orienter, comment choisir sans passer beaucoup de temps à étudier de nombreuses docs un peu au hasard ?

P-S : J'oubliais de préciser que j'utilise Linux (et des logiciels libres) pour l'ordinateur où je veux créer mes bases de données. Mais une solution adaptable à Windows pourrait être un avantage par la suite.

[StringBuilder]

C'est ça que tu cherches, non ?

https://msdn.microsoft.com/fr-fr/library/ff929144.aspx
https://lennilobel.wordpress.com/201...ali-filetable/

[Christian_B]

Bonjour StringBuilder, merci pour tes suggestions.

Mais la première référence (à FILETABLE et FILESTREAM) concerne un outils Microsoft pour Windows alors que je travaille actuellement sous Linux (en principe avec des logiciels libres).
Même si je voulais copier une partie de mes bases sur mon portable sous Windows, il faudrait une solution qui soit transférable d'un système de fichiers à l'autre. Je n'en suis pas là et une solution pour Linux ferait mon affaire actuellement.
La 2ème solution concerne des BLOB qui seraient stockés si je comprends bien dans la base alors que je veux accéder à des fichiers (notamment à mes répertoires actuels) dont seule une référence (inode ou chemin) est dans la base.

Mon pb est de trouver des références (ouvrages, sites) qui me permettraient de choisir entre les solutions existantes.

[StringBuilder]

En SGBD libre, y'a que PostgreSQL (les autres sont des similis ersatz de ce qui se faisait de pire il y a 20 ans).

Mais PostgreSQL ne comporte pas l'ombre du début d'une ligne de code qui pourrait répondre à ton besoin.

Ensuite, sache que :
- En termes de SGBD il vaut mieux respecter la norme que de faire du libre
- Que SQL Serveur propose plusieurs versions gratuites
- Qu'il existe même un version Linux (attention, pas certain qu'elle supporte FILETABLE ceci dit)

SQL Server est le seul SGBD à ma connaissance à proposer ces mécanismes de gestion de fichiers avec un pont direct entre base de données et système de fichiers.


Il te reste donc deux solutions :
- gérer des "chemins de fichiers" dans ta base, sans aucun moyen de travailler avec les fichiers depuis SQL, et aucun support intégrité entre BDD et Filesystem
- gérer les fichiers sous forme d BLOB avec tous les points négatifs que cela implique : Performances catastrophiques utilisation difficile, requêtage chauchemardesque et pas d'accès aux fichiers à travers le filesystem

Bref, bon retour dans les années 80. T'as prévu une K7 de 90 minutes pour faire ta sauvegarde ?

[Waldar]

Oui, ou sinon il y a Oracle qui fait tout ça très bien aussi.
C'est un peu plus ténu au niveau de la configuration que son concurrent de MS, mais ça fonctionne.

[StringBuilder]

En effet, j'ai pas évoqué Oracle, dont je ne suis absolument plus les avancées.
Quitte à partir sur un truc non libre, autant partir sur quelque-chose d'abordable et qui respecte un peu les normes (Oracle a un peu de mal à faire des efforts dans ce sens, je sais pas si ça évolue dans le bon sens).

Je n'ai pas exemple pas la moindre idée si Oracle XE permet ce genre de chose. Si oui, ça peut devenir une bonne alternative à SQL Server sous Linux si ce dernier ne supporte pas FILETABLE sous Linux.

[Christian_B]

En SGBD libre, y'a que PostgreSQL (les autres sont des similis ersatz de ce qui se faisait de pire il y a 20 ans).
Mais PostgreSQL ne comporte pas l'ombre du début d'une ligne de code qui pourrait répondre à ton besoin.
En termes de SGBD il vaut mieux respecter la norme que de faire du libre

Concernant l'utilisation du libre pour les SGBD, notamment PostgreSQL, j'ai eu l'occasion de voir (avant d'être à la retraite) qu'il était utilisé pour des applis professionnelles autrement complexes et volumineuses que la base personnelle que j'envisage. Je pense que ton point de vue ne fait pas l'unanimité. Je préfère largement utiliser le libre qu'être à la norme.
Par contre Si PostgreSQL ou d'autres SGBD libres ne proposent pas de solution interne, je devrai sans doute voir les choses autrement et chercher un moyen extérieur plus compliqué, je suppose un langage de programmation pour lequel le SGBD sera seulement un réservoir de données. Je présume que les applis du style "gestion de photos", par exemple, procèdent de cette manière.
Il me reste à trouver le langage qui me facilite les choses pour une appli assez modeste, en facilitant notamment la réalisation d'une interface graphique (sans fioritures). Car mon expérience en programmation est limitée et assez ancienne.

- Que SQL Serveur propose plusieurs versions gratuites
- Qu'il existe même un version Linux (attention, pas certain qu'elle supporte FILETABLE ceci dit)
SQL Server est le seul SGBD à ma connaissance à proposer ces mécanismes de gestion de fichiers avec un pont direct entre base de données et système de fichiers.

Je vais quand même essayer de voir de ce côté si cela me donne une solution possible (sous Linux).

Bref, bon retour dans les années 80. T'as prévu une K7 de 90 minutes pour faire ta sauvegarde ?

Là tu charries, même mes premiers ordinateurs (Oric, Amiga) n'avaient plus de cassettes. Passons

[SQLpro]

Concernant l'utilisation du libre pour les SGBD, notamment PostgreSQL, j'ai eu l'occasion de voir (avant d'être à la retraite) qu'il était utilisé pour des applis professionnelles autrement complexes et volumineuses que la base personnelle que j'envisage. Je pense que ton point de vue ne fait pas l'unanimité. Je préfère largement utiliser le libre qu'être à la norme.

Réflexe non professionnel... Une fois capturé par les spécificités d'un système non libre et lorsque vous serez dans une impasse technique il ne vous restera plus qu'à payer le prix fort pour un outil qui le fera avec le libr (par exemple Entreprise DB pour PostGreSQL...) ou bien encore migrer toutes votre infra.... !

Par contre Si PostgreSQL ou d'autres SGBD libres ne proposent pas de solution interne, je devrai sans doute voir les choses autrement et chercher un moyen extérieur plus compliqué, je suppose un langage de programmation pour lequel le SGBD sera seulement un réservoir de données. Je présume que les applis du style "gestion de photos", par exemple, procèdent de cette manière.

À moins que vous ayez quelques dizaines d'années/homme à consacrer pour ce faire, intégrer une gestion de fichier dans un noyau SQL, même libre est une chose complexe et arduee, raison pour laquelle cela n'existe pas dans le libre.
Cependant un tel mécanisme fait partie de la norme SQL sous le nom de DATALINK (voir mon livre sur le langage SQL)

Il me reste à trouver le langage qui me facilite les choses pour une appli assez modeste, en facilitant notamment la réalisation d'une interface graphique (sans fioritures). Car mon expérience en programmation est limitée et assez ancienne.

Pensez simplement qu'il vous faudra encapuler toutes les opérations systèmes de bas niveau entreprises sur les fichiers et répertoires (créations, modification suppression, mises à jours de métadonnées...) au sein de transactions pilotées à haut niveau par le moteur SQL, avec le niveau d'isolation minimal nécessaire, et en synchronisant les verrous SQL avec les verrous système et bien entendu de manière multithreadée...
Bon courage !!!

Je vais quand même essayer de voir de ce côté si cela me donne une solution possible (sous Linux).

Là tu charries, même mes premiers ordinateurs (Oric, Amiga) n'avaient plus de cassettes. Passons

Sachez qu'il existe une version Linux de SQL Server à l'état de Bétà test pour certains grands compte et qui sera disponible fin 2017.

A +

[StringBuilder]

Sachez qu'il existe une version Linux de SQL Server à l'état de Bétà test pour certains grands compte et qui sera disponible fin 2017.

Au temps pour moi, je croyais que la version Linux était déjà disponible.

Ça explique sans doute pourquoi j'ai jamais trouvé le lien pour le télécharger ^^

[SQLpro]

Au temps pour moi, je croyais que la version Linux était déjà disponible.

Ça explique sans doute pourquoi j'ai jamais trouvé le lien pour le télécharger ^^

Oui, j'y ais même pas eu droit !!!!

A +

[Christian_B]

À moins que vous ayez quelques dizaines d'années/homme à consacrer pour ce faire, intégrer une gestion de fichier dans un noyau SQL, même libre est une chose complexe et arduee, raison pour laquelle cela n'existe pas dans le libre.

Je ne comprends pas bien cette réponse à mon idée de chercher un langage de programmation qui fait le lien entre système de fichiers d'une part et SGBD d'autre part.
Je ne songeais nullement à modifier un outil SQL, ce qui est bien au-delà de mes compétences, mais à chercher un langage qui :
- d'une part possèderait déjà des fonctions d'accès au système de fichiers
- d'autre part pourrait accéder à la base de données (en utilisant des requêtes SQL)
- permettent sans trop de difficultés d'afficher graphiquement une combinaison de ces deux sources, par exemple des infos de l'en-tête de fichiers + des infos complémentaires de la base, ou encore d'inscrire dans la base certaines infos récupérées dans les fichiers. Autrement dit, j'ai plus ou moins renoncé à l'idée de lancer directement des applis extérieures directement depuis un formulaire (sauf nouvelle info encourageante).

Est-ce que des langages comme C, Python, PHP ou autres ne savent pas faire cela ? J''étais persuadé que cela existait, sans avoir d'infos précises sur le sujet. Sinon comment font les concepteurs de logiciels (imagerie, etc) ou de sites internet utilisant une base ?
J'ai l'impression que pour en avoir le cœur net, je vais devoir bel et bien fouiller dans les docs des différents langages qui semblent pouvoir accéder à des SGBD.
Par exemple en cherchant "PostgreSQL" dqns Synaptic, je trouve : clisp-module-postgresql ; llibdbi-perl ; odbc-postgresql ; pgagent ; php5-pgsql ; postgresql-plpython-9.3 (et d'autre pour python) ; ruby-dataobjects-postgres (et d'autres pour Ruby) ; sans compter les nombreux paquets qui ne me disent rien.
Mon pb est de m'orienter dans ce maquis et de savoir qu'est ce qui pourrait m'être le plus utile sans tout examiner. Et encore ce ne sont que des exemples pour PostgreSQL. Je n'exclue rien à priori, pas même une base bureautique genre LibreOffice Base si cela s'avérait plus simple, suffisant et raisonnablement fiable.

P-S : Je n'ai effectivement pas des "réflexes professionnels" car je me place dans l'optique d'un amateur qui cherche à réaliser un environnement à usage personnel.
Par exemple une base "Cinéma" (films, réalisateurs, acteurs, DVD, etc) qui viendrait compléter, référencer ou récupérer partiellement des infos diverses que j'ai dans des répertoires (images, bandes-annonces, documents, raccourcis internet ..).

[SQLpro]

Je ne comprends pas bien cette réponse à mon idée de chercher un langage de programmation qui fait le lien entre système de fichiers d'une part et SGBD d'autre part.
Je ne songeais nullement à modifier un outil SQL, ce qui est bien au-delà de mes compétences, mais à chercher un langage qui :
- d'une part possèderait déjà des fonctions d'accès au système de fichiers
- d'autre part pourrait accéder à la base de données (en utilisant des requêtes SQL)
- permettent sans trop de difficultés d'afficher graphiquement une combinaison de ces deux sources, par exemple des infos de l'en-tête de fichiers + des infos complémentaires de la base, ou encore d'inscrire dans la base certaines infos récupérées dans les fichiers.

Tout cela la plupart des langage de type L4G et objet le font. Mais là n'est pas le problème...

Autrement dit, j'ai plus ou moins renoncé à l'idée de lancer directement des applis extérieures directement depuis un formulaire (sauf nouvelle info encourageante).

Est-ce que des langages comme C, Python, PHP ou autres ne savent pas faire cela ? J''étais persuadé que cela existait, sans avoir d'infos précises sur le sujet.

Effectivement il le font.

Sinon comment font les concepteurs de logiciels (imagerie, etc) ou de sites internet utilisant une base ?

Il ne s'agit pas uniquement de faire cela. La problématique est de gérer les fichiers de la même manière que les données relationnelles. Ce qui implique de piloter une transaction SQL pour toutes les opérations conjointes de manipulation des fichiers dans le cadre de la base.
Je m'explique plus en avant...
Si vous devez faire par exemple une gestion d'imagerie numérique pour le médical par exemple (ça tombe bien, car j'ai conçut un tel système il y a 10 ans pour ma première entreprise...). Imaginons qu'au moment de vouloir intégrer une image le PC client tombe en panne. Dans quel état se trouvent les données ? Ou est l'image ? A t-elle été stockée sur le serveur ? Le lien données de table / fichier image est-il valide ??? Tout autant de question qui se règlent simplement si le moteur SQL est capable de gérer les transactions aussi bien sur les opérations de fichiers que sur les mises à jour de tables... Autre problématique, la sauvegarde ! Sachant qu'il est impossible de savoir quand une sauvegarde va se terminer, que ce soit pour une base ou pour un système de fichier, vous n'aurez jamais la possibilité se sauvegarder de manière synchronie la base et les fichiers qui vont avec.... À la restauration il manquera des fichiers ou il y aura des fichiers image orphelin.
Notre application permettait de gérer cela sans aucun problème avec SQL Server et le stockage FILESTREAM. Et c'est indispensable pour un hôpital qui fonctionne 24h sur 24, car il serait catastrophique si on disait à un patient au urgences "ha ben va falloir refaire les radio parce ce que le connard d'informaticien à préférer utiliser PostGreSQL qui ne sait pas transactionner les fichiers en base et que le poste client est partit en erreur " !!!

J'ai l'impression que pour en avoir le cœur net, je vais devoir bel et bien fouiller dans les docs des différents langages qui semblent pouvoir accéder à des SGBD.
Par exemple en cherchant "PostgreSQL" dqns Synaptic, je trouve : clisp-module-postgresql ; llibdbi-perl ; odbc-postgresql ; pgagent ; php5-pgsql ; postgresql-plpython-9.3 (et d'autre pour python) ; ruby-dataobjects-postgres (et d'autres pour Ruby) ; sans compter les nombreux paquets qui ne me disent rien.
Mon pb est de m'orienter dans ce maquis et de savoir qu'est ce qui pourrait m'être le plus utile sans tout examiner. Et encore ce ne sont que des exemples pour PostgreSQL. Je n'exclue rien à priori, pas même une base bureautique genre LibreOffice Base si cela s'avérait plus simple, suffisant et raisonnablement fiable.

P-S : Je n'ai effectivement pas des "réflexes professionnels" car je me place dans l'optique d'un amateur qui cherche à réaliser un environnement à usage personnel.
Par exemple une base "Cinéma" (films, réalisateurs, acteurs, DVD, etc) qui viendrait compléter, référencer ou récupérer partiellement des infos diverses que j'ai dans des répertoires (images, bandes-annonces, documents, raccourcis internet ..).

Toute la problématique est : voulez vous faire un logiciel pro ou pour amateur ?

Sur ce sujet en particulier lisez mon livre sur SQL :

Au chapitre sur les types de données vous trouverez les mécanisme liés au DATALINK (norme SQL de 1999) qui se consacre à cette partie et a été implémenté pour SQL Server sous le concept de FILESTREAM et sous Oracle sous le concept de BFile.

A +

[Christian_B]

Tout cela la plupart des langage de type L4G et objet le font.

C'est encourageant. Cela me conforte dans l'optique où je me place maintenant.

Mais là n'est pas le problème. [...] La problématique est de gérer les fichiers de la même manière que les données relationnelles. Ce qui implique de piloter une transaction SQL pour toutes les opérations conjointes de manipulation des fichiers dans le cadre de la base. [...]
Si vous devez faire par exemple une gestion d'imagerie numérique pour le médical [..]
Autre problématique, la sauvegarde ! Sachant qu'il est impossible de savoir quand une sauvegarde va se terminer, que ce soit pour une base ou pour un système de fichier, vous n'aurez jamais la possibilité se sauvegarder de manière synchronie la base et les fichiers qui vont avec [...]
Notre application permettait de gérer cela sans aucun problème avec SQL Server et le stockage FILESTREAM.[...]
Toute la problématique est : voulez vous faire un logiciel pro ou pour amateur ?

Clairement, je ne me situe pas dans une optique aussi contraignante. En ce qui concerne les sauvegardes, je peux éviter toute modification pendant des sauvegardes ponctuelles qui concernent aussi bien les répertoires concernés que la base (située dans le même volume).
Et puisque FILESTREAM n'est pas actuellement banalisé et disponibles pour Linux et pour les SGBD que j'envisage, je cherche forcément d'autres solutions, même moins parfaites.
Merci en tout cas, une partie de vos réponses m'aide à voir ce qui est possible ou non dans mes limites.

[StringBuilder]

L'alternative (pourrie) à FILESTREAM, c'est le type "BLOB" (ou IMAGE, ou VARBINARY au autre, selon le SGBD).

Le défaut de ce type, c'est que les données des fichiers sont mélangées en plein milieu des données.

C'est à dire qu'à la lecture des données, si on souhaite simplement rechercher toutes les images qui s'appelle "RADIO%" et qui sont de type "JPG", alors le disque va devoir faire des sauts de moutons pour sauter chaque "blob" (potentiellent plusieurs Mo chacuns) alors qu'il n'est sensé analyser que des données de petite taille (titre et extension, qui feront au maximum quelques dizaines d'octets).

FILESTREAM dipose aussi de nombreux autres avantages, mais l'aspect performance est de loin celui qui doit retenir le plus votre attention. BLOB est lent, très lent, de part sa conception.

Ensuite, ce qu'on fait souvent, et j'imagine que c'est ce que vous cherchez à faire au final, c'est d'avoir dans un répertoire les fichiers, de dans une base les informations relatives aux fichiers.

On fait généralement le lien simplement en stockant dans la base le chemin d'accès au fichier.
C'est une alternative performante : la base ne gère que les attributs du fichier (titre, film, acteur, etc.) et le système de fichier gère les fichiers (et c'est ce qu'il fait de mieux)

Mais attention comme le souligne SQLpro, votre programme ne pourra pas alors garantir d'aucune manière la cohérence des données :
- Que se passe-t-il si quelqu'un ajoute des images sans les référencer dans la base ?
- Que se passe-t-il si quelqu'un supprime des images sans mettre à jour la base ?
- Que se passe-t-il si quelqu'un crée des informations dans la base et oublie de mettre les images ?
- Que se passe-t-il si quelqu'un supprime des informations dans la base et oublie de supprimer les images ?

Et là je ne parle que des cas "simples".
=> On devra alors faire un scan COMPLET de tous les fichiers sur le disque et de toutes les données dans la base pour s'assurer que tout est bien lié.

Mais que se passe-t-il si une mise à jour de masse à lieu ? (déplacement d'un répertoire contenant plusieurs images)
=> Le scan va détecter des anomalies, mais sera incapable de refaire les liens.

Bref, un casse-tête qui bien souvent sonne le glas d'une application mal conçue au départ

[Waldar]

L'alternative (pourrie) à FILESTREAM, c'est le type "BLOB" (ou IMAGE, ou VARBINARY au autre, selon le SGBD).
Le défaut de ce type, c'est que les données des fichiers sont mélangées en plein milieu des données.

C'est à dire qu'à la lecture des données, si on souhaite simplement rechercher toutes les images qui s'appelle "RADIO%" et qui sont de type "JPG", alors le disque va devoir faire des sauts de moutons pour sauter chaque "blob" (potentiellent plusieurs Mo chacuns) alors qu'il n'est sensé analyser que des données de petite taille (titre et extension, qui feront au maximum quelques dizaines d'octets).

Non, les LOB ont des espaces de stockage dédiés.
Dans la table il n'y a qu'un pointeur vers cet espace.

BLOB est lent, très lent, de part sa conception.

Du coup, non. On n'ouvre que les BLOB dont on a besoin au moment où on en a besoin.

[Christian_B]

L'alternative (pourrie) à FILESTREAM, c'est le type "BLOB" (ou IMAGE, ou VARBINARY au autre, selon le SGBD).
Le défaut de ce type, c'est que les données des fichiers sont mélangées en plein milieu des données.

Non, les LOB ont des espaces de stockage dédiés.
Dans la table il n'y a qu'un pointeur vers cet espace.

J'ai bien précisé que je voulais référencer mes fichiers dans la base et en aucun cas faire une base énorme contenant tout.
Tout stocker comme BLOB (ce que je ne sais d'ailleurs pas faire à partir de mes données actuelles dans des fichiers) ne résoudrait pas mon pb d'ouvrir ces objets avec l'application appropriée pour chaque type d'objet. Je me demande bien comment ceux qui créent des BLOB font pour les utiliser.

FILESTREAM dispose aussi de nombreux autres avantages, mais l'aspect performance est de loin celui qui doit retenir le plus votre attention.

Comme déjà dit, puisque FILESTREAM n'est pas disponible dans mon environnement, je ferai autrement.

Ensuite, ce qu'on fait souvent, et j'imagine que c'est ce que vous cherchez à faire au final, c'est d'avoir dans un répertoire les fichiers, de dans une base les informations relatives aux fichiers. On fait généralement le lien simplement en stockant dans la base le chemin d'accès au fichier.

C'est exactement ce que j'envisageais comme je pense l'avoir clairement dit.

Mais attention comme le souligne SQLpro, votre programme ne pourra pas alors garantir d'aucune manière la cohérence des données :
- Que se passe-t-il si quelqu'un ajoute des images sans les référencer dans la base ?
- Que se passe-t-il si quelqu'un supprime des images sans mettre à jour la base ?
- Que se passe-t-il si quelqu'un crée des informations dans la base et oublie de mettre les images ?
- Que se passe-t-il si quelqu'un supprime des informations dans la base et oublie de supprimer les images ? [...]
=> On devra alors faire un scan COMPLET de tous les fichiers sur le disque et de toutes les données dans la base pour s'assurer que tout est bien lié.

Puisque je m'oriente vers une programme extérieur (faute de solution purement SGBD à ma portée) la question de ce que je pourrai faire sans trop de complications dépend des bibliothèques de fonctions disponibles dans le langage choisi. Ce n'est plus un problème SQL. C'est maintenant de ce type d'info que j'ai besoin, peut-être devrais-je reposer ce pb sur un autre forum que SGBD ?
Selon les difficultés, je peux à la rigueur renoncer à référencer les images et autres documents , mais me limiter aux répertoires correspondant à un sujet précis pour lequel je crée une fiche. Par exemple les répertoire consacrés à un film, dans une base Cinéma. L'idéal serait alors (pour toute création, modification de chemin ou suppression d'un tel répertoire) de faire l'opération en même temps par mon appli côté système de fichiers et côté inscription dans la base.

[StringBuilder]

Non, les LOB ont des espaces de stockage dédiés.
Dans la table il n'y a qu'un pointeur vers cet espace.


Du coup, non. On n'ouvre que les BLOB dont on a besoin au moment où on en a besoin.

Tu es certain que c'est le cas sur les SGBD "libre" (j'entends par là, à minima PostgreSQL et éventuellement MySQL) ?

En effet, il a quelques années (SQL Server 7.0 et Oracle 8), donc ça remonte un peu, "on" m'avait clairement stipulé que les LOB étaient noyés au milieu des données.
Ou si ceci n'est vrai que d'un point de vue tablespace, dans la mesure où c'est bien séparé, mais obligatoirement dans le même fichier ?

[StringBuilder]

Puisque je m'oriente vers une programme extérieur (faute de solution purement SGBD à ma portée) la question de ce que je pourrai faire sans trop de complications dépend des bibliothèques de fonctions disponibles dans le langage choisi. Ce n'est plus un problème SQL. C'est maintenant de ce type d'info que j'ai besoin, peut-être devrais-je reposer ce pb sur un autre forum que SGBD ?
Selon les difficultés, je peux à la rigueur renoncer à référencer les images et autres documents , mais me limiter aux répertoires correspondant à un sujet précis pour lequel je crée une fiche. Par exemple les répertoire consacrés à un film, dans une base Cinéma. L'idéal serait alors (pour toute création, modification de chemin ou suppression d'un tel répertoire) de faire l'opération en même temps par mon appli côté système de fichiers et côté inscription dans la base.

Ben...

T'as le choix. Je pense que tu auras du mal à trouver un langage avec lequel c'est impossible... Même en *.bat tu dois avoir moyen de faire ce que tu veux !

Donc C#, Java, PHP, Phyton, ou n'importe quoi d'autre et ça ira.
Le seul langage à ma connaissance qui ne pourra pas faire ça, c'est JavaScript car pas d'accès aux données possible sans passer par un composant serveur (potentiellement écrit en JS ceci dit, si tu trouves un serveur d'application qui l'accepte).

[StringBuilder]

Sinon, pour en revenir à l'utilisation de BLOB et de programmes externes, une solution classique :
- Lancer les programmes externes à partir d'une application : c'est ce que fait outlook par exemple quand tu ouvres une pièce jointe : il n'ouvre pas directement le fichier à partir du fichier *.msg, mais l'extrait, en fait une copie dans un dossier temporaire. A toi ensuite de détecter quand le programme client n'utilise plus le fichier, et de le réimporter à ce moment)

[DotNetMatt]

Non, les LOB ont des espaces de stockage dédiés.
Dans la table il n'y a qu'un pointeur vers cet espace.


Du coup, non. On n'ouvre que les BLOB dont on a besoin au moment où on en a besoin.

J'avais eu le cas sur un projet code (avec les pieds) sur MySQL, ils stockaient une masse enorme de documents Word sous forme de blobs. C'etait d'une lenteur absolue, meme si on ne chargeait le blob qu'au tout dernier moment, lorsqu'on en avait besoin. Peut-etre que le moteur de MySQL ne separe pas aussi bien que peuvent le faire SQL Server/Oracle/PGSQL?

@Waldar qu'en penses-tu ?

La solution avait ete de migrer vers SQL Server + FILESTREAM et la, o^ miracle, les temps d'execution sont passes a quelques millisecondes.