On a Mac, you'd e.g. use and mount a disk image if you wanted to create a filesystem inside of a file. Windows has virtual hard drives, and you can do that kind of thing on Linux too.
I don't understand why you'd ever want to use a relational database for that. It's a completely different paradigm.
Although I also don't really understand why you're worried about cluttering up a directory. And if it's transient, it's that when temp dirs are for?
> I don't understand why you'd ever want to use a relational database for that. It's a completely different paradigm.
Well, it might be a relation DB or else a zipfile. Why couldn't I encapsulate a file tree in a single file ? Maybe it's tens of thousands of quite small files.
You can put tens of thousands of files in a single file lots of ways that are expressly designed for that. You don't need SQLite for that.
So why would you want to use SQLite for that is my question? Mounting a database or a table as a filesystem doesn't make much sense to me. There's a very poor fit between the two paradigms. What does a subdirectory mean in a database? What does a foreign key or set of columns mean in a filesystem?
Maybe you misunderstand the scenario. An SQLite DB can have records where each record contains a path. This column can be used to emulate a hierarchical tree-type filesystem. There's a few different ways to represent the path information, and the parent-child connectivity among records.
No, you asked about mounting specifically. And I replied:
> On a Mac, you'd e.g. use and mount a disk image if you wanted to create a filesystem inside of a file. Windows has virtual hard drives, and you can do that kind of thing on Linux too.
So why wouldn't you use one of these if you need mounting? They're literally made for it.
I continue to not understand why you would want to mount a SQLite database instead of using one of these.
