> In a RDBMS an index is already storing references in a tree format. If you map that to files and folders you now have basically the same thing as a file system.
Yeah, a file system stores general data so it is very easy to map it to an RDBMs that also stores general data.
But what this is identifying that once the relational nature of the data isn't a factor, the best lookup structure is a tree.
You don't need the relational aspect per se, but if you have indexes by filename, filetype, creation date and size (which I do not find unreasonable). It becomes trivially fast to ask the question:
> Give me all image files > 100 KiB from 31. December 2021 to 1. January 2022
While in current file systems you need to scan the entire content of file metadata to get that information. It will take a long time, especially if you have a lot of small files (think Windows C: drive).
That might not be something the average user would do by themselves, but developers of, say, image processing apps certainly would.
Might be the next big thing. But if that is a valuable feature it is _really_ easy to implement. App, sqlite, scan file system once, build up a database of metadata then put 3 indexes on it. I expect a lot of photo apps can already do that.
But all that still isn't really leveraging the power of the relational model. That is simply indexing files on a lot of different attributes, ie, leveraging an RDBMS implementation detail where they use trees. The point of the relational model is relational algebra (SELECT, JOIN & WHERE in SQL terms). And WHERE isn't the interesting one out of those 3, it is JOIN.
If the use case for a relational filesystem is interesting filters then it sounds a lot like a false start.
Of course it's simple to do for every app. But they have to keep that database updated. Either by running a service and listening to all changes to the file system or by running it from scratch every so often. Neither is a good idea from a performance point of view.
I can see where you're coming from with the false start if looking at it from that isolated point of view. I see it more as the first step to storing data, in general, in an RDBMS and once applications start to utilize that, new use cases will start to emerge. Linux in particular with it's "everything is a file" philosophy seems to suited to use this model. A table for processes, files, network connections, ect.
Go meta, and consider projecting distinct hierarchies on document collections. For example, I may have a hierarchical view of my documents organized by content matter, and another one organized by projects, etc. So there is your JOIN.
Yeah, a file system stores general data so it is very easy to map it to an RDBMs that also stores general data.
But what this is identifying that once the relational nature of the data isn't a factor, the best lookup structure is a tree.