Je ne suis pas une informaticien a la base, et j'avoue parfois avoir du mal a bien différentier un file systeme d'une base de donnée, surtout quand je lis que beaucoup des idées de reiserFS 4 sont venue suite a l'etude des BD...
D'ou mon idée candide d'utiliser directement une BD a la place du FS...
Un FS et une BD reposent sur le même principe, c'est vrai. De la même manière qu'un microphone repose sur le même principe qu'un écouteur. Et effectivement on peut faire faire le travail d'un FS à une BD (ce que tu proposes) ou l'inverse (mais ça fournit une BD largement moins riche que ce qui existe aujourd'hui).
En fait, FS et BD visent le même problème, stocker des données, mais en mettant l'accent sur différents aspects de ce problème. Dans un FS, ce qui importe c'est d'avoir un accès rapide, les fonctionnalités de recherche/classement sont optionelles. On a donc une structure "relativement" simple et uniforme pour tout les fichiers, et un nombre restreint et figé (sauf dans le cas des EAs, dont je parlais plus haut) de "champs" (les attributs, ceux que ls te montre).
Dans une BD, les performances sont moins primordiales, mais en échange on désire pouvoir utiliser une algèbre sophistiquée (généralement l'algèbre "relationelle") pour faire des manipulations avancées (recherche, sélection de sous-ensembles, fusion de deux données différentes, etc.).
La différence de design entre les deux tient principalement à un consensus différent en matière d'équilibre fonctionnalités/performances. Certains projets visent à introduire de nouveaux consensus intermédiaires, comme les attributs étendus ou les systèmes d'indexation de fichiers.
Cependant, il faut bien garder à l'esprit que les premiers essais de filesystem de BeOS étaient de véritables SGBD, mais ont été abandonnés pour cause de performances déplorables (au bénéfice du système actuel, avec un FS "classique" amélioré).
[^] # Re: Du cote de Gnome
Posté par Larry Cow . En réponse au journal Une base de données pour /home ?. Évalué à 3.
Un FS et une BD reposent sur le même principe, c'est vrai. De la même manière qu'un microphone repose sur le même principe qu'un écouteur. Et effectivement on peut faire faire le travail d'un FS à une BD (ce que tu proposes) ou l'inverse (mais ça fournit une BD largement moins riche que ce qui existe aujourd'hui).
En fait, FS et BD visent le même problème, stocker des données, mais en mettant l'accent sur différents aspects de ce problème. Dans un FS, ce qui importe c'est d'avoir un accès rapide, les fonctionnalités de recherche/classement sont optionelles. On a donc une structure "relativement" simple et uniforme pour tout les fichiers, et un nombre restreint et figé (sauf dans le cas des EAs, dont je parlais plus haut) de "champs" (les attributs, ceux que ls te montre).
Dans une BD, les performances sont moins primordiales, mais en échange on désire pouvoir utiliser une algèbre sophistiquée (généralement l'algèbre "relationelle") pour faire des manipulations avancées (recherche, sélection de sous-ensembles, fusion de deux données différentes, etc.).
La différence de design entre les deux tient principalement à un consensus différent en matière d'équilibre fonctionnalités/performances. Certains projets visent à introduire de nouveaux consensus intermédiaires, comme les attributs étendus ou les systèmes d'indexation de fichiers.
Cependant, il faut bien garder à l'esprit que les premiers essais de filesystem de BeOS étaient de véritables SGBD, mais ont été abandonnés pour cause de performances déplorables (au bénéfice du système actuel, avec un FS "classique" amélioré).
J'espère pas avoir dit trop de conneries :)