Ca répond en partie, c'est un bout de conversation reformaté que j'ai eu avec un pote sur les FS en SGBD (ou assimilés) il y a quelques mois.
Si vous vous posez la question, oui je suis tatoué Apple
SGBD
----
Les filesytems en vigueur s'appuient tous plus ou moins sur les bêtes arborescences, ce qui est très très limité. C'est une abstraction de représentation de données qui répond bien aux limitations de l'humain (quoi qu'on en trouve pour qui c'est déjà trop compliqué), mais qui n'a aucune réalité physique : le matos s'en fout, bien que ça ne soit pas évident sur non-mac (par exemple d'autres FS n'ont pas de FileID, ce qui les confine nécessairement aux notions primitives de chemin d'accès et structure arborescente, c'est-à-dire qu'ils ont transformé en limitations techniques concrètes des choix fonctionnels abstraits, avec pour conséquence que les OS eux-mêmes intègrent ces limitations comme des lois de la nature, bref pas d'alias sur PC).
Certains FS compensent de diverses façons en ajoutant des meta-données, ou en les stockant dans un SGBD séparé plus performant, ou en ajoutant un niveau de complexité au FS (fichiers à 2 branches en HFS dont l'une gérée comme un SGBD par l'OS, FS multi-branches dans NT dont l'intérêt reste à exploiter alors que ça leur aurait presque permis les bundles de Mac OS X -- si ce n'est qu'une des raisons des bundles est de survivre aussi à des FS vraiment plats).
Mais ça reste du caca comparé à un vrai SGBD. En gros dans une base de données il n'y a ni arborescence ni distinction entre les types de données. Rien n'empêche un enregistrement d'être lié à plusieurs contextes et le contenu d'un fichier a le même statut que ses meta-infos: pas de différence par exemple entre chercher dans noms, dates, familles, versions, types, ou contenus et pas de raison de ne pas trouver "bite" dans "trou" parce que tu l'as rangé dans "poil". Sans aller jusque là, M$ travaille à faire passer pour SGBD son futur FS, qui à ma connaissance ne sera que l'ajout d'une couche SGBD séparée en plus de données plates traditionnelles (en espérant mieux que Joliet qui en séparant les couches d'ancien et nouveau avait l'immense avantage de pouvoir zaper les noms longs en cas de problème -- c'est arrivé à mon frère à l'époque de W95, peut-être pour d'autres raisons ressemblant à ce qui nous arrive quand on fait passer du HFS+ à travers une couche trop primitive pour unicode et 256 chars, comme AppleShare pre-X --, et en espérant mieux que les commentaires pre-X, qui sont stockés avec d'autres trucs séparément du FS et ont longtemps disparu aux reconstructions de la BDD "Desktop", elles-mêmes rendues nécessaires par les désynchronisations dues à cette dissociation).
Apple discrétos
---------------
Comme tu sais ils ont embauché un Be peu avant d'ajouter la journalisation, qui était l'une des caractéristiques de BeOS (nixe le risque de désynchronisations structurelles). L'autre caractéristique du FS de Be était le SGBD à meta-données de la mort. http://www.rebolfrance.net/articles/beos/beos_database.pdf(...)
Actuellement les mises à jour X convergent doucement vers ça, de façon visible (recherche vaguement dynamique du Finder) ou non (moteur d'indexation et APIs de recherches), ce qui pourrait préparer une base fonctionnelle avant un saut technique (faire entrer doucement les pignoufs et leur servir des consos en attendant le moment de les coller au mur en allumant les 12 KW, le dance floor et la boule à paillettes).
10 ans de retard
----------------
Fonctionnellement les avantages potentiels sont Kaulossaux, comme Copland et BeOS en donnaient déjà un aperçu :
Quelque chose comme les smart playlists d'iTunes -- stocker une recherche en gros comme un "dossier dynamique" sans rapport particulier avec l'éventuelle structure hiérarchique. (en étant vraiment velu je pourrais scripter les actions de dossiers pour émuler ce genre de fonctionnalité, mais ça resterait du bricolage limité par l'obligation de déplacer les trucs ou en faire des alias ; sous ouin n'en parlons pas, ni actions de dossiers ni alias)
Meta-données en liberté -- dans BeOS les fichiers ne sont pas juste des zones de la surface du disque associées à des noms quelque part dans l'arborescence et quelques autres détails prévus comme dates et versions, mais aussi tout autre information associée librement, avec le même statut, de même que tout fichier mac peut contenir tout type de meta-donnée dans la branche ressource, si ce n'est que le ressource manager est distinct, loin au-dessus du FS, et trop limité pour être attaqué transversalement (il gère les ressources des quelques 10aines ou 100aines de fichiers ouverts mais éclate à quelques 10aines de milliers de ressources et quelques 10aines de Megs, pas assez pour gérer tous les fichiers d'un volume). Par exemple il y a sous BeOS des trucs ressemblant à MP3Rage qui créent des champs de meta-données à partir des tags ID3, à la différéence qu'un mac n'en fait pas grand chose une fois qu'elles sont dans les quelques champs fixés d'avance - noms (filesystem), versions (resources), ou commentaires (desktop DB), et pratiquement rien s'il nous prenait de créer des ressources plus libres que ça (comme ressources ANPA/IPTC utilisés par ToShop, GraphicConverter et les catalogueurs mais ignorées par le Finder et tout le reste), alors que BeOS en fait tout ce que tu n'oses imaginer (attributs créés pour l'occasion, sans limite de taille, recherches de fou, mais aussi rien n'oblige à présenter les fichiers par leurs noms : le Tracker de BeOS peut très bien n'afficher que telle ou telle autre meta-donnée). Pour des MP3 l'usage est évident: mettre les tags dans des attributs du FS et se passer des noms de fichiers.
[^] # Re: Spotlite/WinFS et ce genre de choses.
Posté par xylpho . En réponse à la dépêche Mac OS X et les technologies du libre. Évalué à 10.
Si vous vous posez la question, oui je suis tatoué Apple
SGBD
----
Les filesytems en vigueur s'appuient tous plus ou moins sur les bêtes arborescences, ce qui est très très limité. C'est une abstraction de représentation de données qui répond bien aux limitations de l'humain (quoi qu'on en trouve pour qui c'est déjà trop compliqué), mais qui n'a aucune réalité physique : le matos s'en fout, bien que ça ne soit pas évident sur non-mac (par exemple d'autres FS n'ont pas de FileID, ce qui les confine nécessairement aux notions primitives de chemin d'accès et structure arborescente, c'est-à-dire qu'ils ont transformé en limitations techniques concrètes des choix fonctionnels abstraits, avec pour conséquence que les OS eux-mêmes intègrent ces limitations comme des lois de la nature, bref pas d'alias sur PC).
Certains FS compensent de diverses façons en ajoutant des meta-données, ou en les stockant dans un SGBD séparé plus performant, ou en ajoutant un niveau de complexité au FS (fichiers à 2 branches en HFS dont l'une gérée comme un SGBD par l'OS, FS multi-branches dans NT dont l'intérêt reste à exploiter alors que ça leur aurait presque permis les bundles de Mac OS X -- si ce n'est qu'une des raisons des bundles est de survivre aussi à des FS vraiment plats).
Mais ça reste du caca comparé à un vrai SGBD. En gros dans une base de données il n'y a ni arborescence ni distinction entre les types de données. Rien n'empêche un enregistrement d'être lié à plusieurs contextes et le contenu d'un fichier a le même statut que ses meta-infos: pas de différence par exemple entre chercher dans noms, dates, familles, versions, types, ou contenus et pas de raison de ne pas trouver "bite" dans "trou" parce que tu l'as rangé dans "poil". Sans aller jusque là, M$ travaille à faire passer pour SGBD son futur FS, qui à ma connaissance ne sera que l'ajout d'une couche SGBD séparée en plus de données plates traditionnelles (en espérant mieux que Joliet qui en séparant les couches d'ancien et nouveau avait l'immense avantage de pouvoir zaper les noms longs en cas de problème -- c'est arrivé à mon frère à l'époque de W95, peut-être pour d'autres raisons ressemblant à ce qui nous arrive quand on fait passer du HFS+ à travers une couche trop primitive pour unicode et 256 chars, comme AppleShare pre-X --, et en espérant mieux que les commentaires pre-X, qui sont stockés avec d'autres trucs séparément du FS et ont longtemps disparu aux reconstructions de la BDD "Desktop", elles-mêmes rendues nécessaires par les désynchronisations dues à cette dissociation).
Apple discrétos
---------------
Comme tu sais ils ont embauché un Be peu avant d'ajouter la journalisation, qui était l'une des caractéristiques de BeOS (nixe le risque de désynchronisations structurelles). L'autre caractéristique du FS de Be était le SGBD à meta-données de la mort.
http://www.rebolfrance.net/articles/beos/beos_database.pdf(...)
Actuellement les mises à jour X convergent doucement vers ça, de façon visible (recherche vaguement dynamique du Finder) ou non (moteur d'indexation et APIs de recherches), ce qui pourrait préparer une base fonctionnelle avant un saut technique (faire entrer doucement les pignoufs et leur servir des consos en attendant le moment de les coller au mur en allumant les 12 KW, le dance floor et la boule à paillettes).
10 ans de retard
----------------
Fonctionnellement les avantages potentiels sont Kaulossaux, comme Copland et BeOS en donnaient déjà un aperçu :
Quelque chose comme les smart playlists d'iTunes -- stocker une recherche en gros comme un "dossier dynamique" sans rapport particulier avec l'éventuelle structure hiérarchique. (en étant vraiment velu je pourrais scripter les actions de dossiers pour émuler ce genre de fonctionnalité, mais ça resterait du bricolage limité par l'obligation de déplacer les trucs ou en faire des alias ; sous ouin n'en parlons pas, ni actions de dossiers ni alias)
Meta-données en liberté -- dans BeOS les fichiers ne sont pas juste des zones de la surface du disque associées à des noms quelque part dans l'arborescence et quelques autres détails prévus comme dates et versions, mais aussi tout autre information associée librement, avec le même statut, de même que tout fichier mac peut contenir tout type de meta-donnée dans la branche ressource, si ce n'est que le ressource manager est distinct, loin au-dessus du FS, et trop limité pour être attaqué transversalement (il gère les ressources des quelques 10aines ou 100aines de fichiers ouverts mais éclate à quelques 10aines de milliers de ressources et quelques 10aines de Megs, pas assez pour gérer tous les fichiers d'un volume). Par exemple il y a sous BeOS des trucs ressemblant à MP3Rage qui créent des champs de meta-données à partir des tags ID3, à la différéence qu'un mac n'en fait pas grand chose une fois qu'elles sont dans les quelques champs fixés d'avance - noms (filesystem), versions (resources), ou commentaires (desktop DB), et pratiquement rien s'il nous prenait de créer des ressources plus libres que ça (comme ressources ANPA/IPTC utilisés par ToShop, GraphicConverter et les catalogueurs mais ignorées par le Finder et tout le reste), alors que BeOS en fait tout ce que tu n'oses imaginer (attributs créés pour l'occasion, sans limite de taille, recherches de fou, mais aussi rien n'oblige à présenter les fichiers par leurs noms : le Tracker de BeOS peut très bien n'afficher que telle ou telle autre meta-donnée). Pour des MP3 l'usage est évident: mettre les tags dans des attributs du FS et se passer des noms de fichiers.