For a deeper Indexed Database API (nested ObjectStores)

Hello,

I recently experimented with this API trying to simulate a file system, but
I am sad to see a lack of depth.

To preserve the environment applications using my tool, I want to create
only one database for my filesystem.

So I create my database, I add a table representing a folder and I save my
files, until this point, it's ok.

The design problem is when I have to simulate a subfolder ...

I then create another database, but it does not seem very clean because the
user of the application should be able to create your own folders,
subfolders and files, and the application using my tool should also be able
to create their own databases data ... there is therefore a risk of
conflict.

Using only one database should therefore go through the creation of a table
folder or subfolder.

Ok, it's doable ... However, it would ruin the performance, because when
you open a database, the API returns an object containing the
objectStoreNames property that contains the list of all tables in the
database.

Assuming that my file system contains thousands of folders and sub-folders,
once the database is opened, the API will have to recover the full list,
while operations to this file system in perhaps one or two concern.

I can store objects in the records of my tables but this would retrieve an
object that can be huge, again, while operations to this file system can be
a concern or two.

None of these solutions seem to me, at once, clean and optimal in terms of
resources.

My idea is that it may be more optimal to save a table in the fields of a
record in another table and could overcome the lack of relationships.

Since a picture is better than a long explanation, here is an example
schema ObjectStores nested:

indexedDB = {
    database: {
        directory_0: {
            subdirectory: {
                // ...
            }
        },
        directory_1: {
            // ...
        },
        file_0.txt,
        file_1.txt
    }
}

For additional and / or feedback information, do not hesitate to contact me.
;)

Michaël