[duped]

In your example you're kind of mixing a DB within a DB (the index.json file is a separate database contained within the main database).

A better structure would be something like

    users/<user>/projects/<name>/data/... etc

Now your file system is just a NoSQL database. All that data you would dump into an index.json can be stored in the file tree.

That would actually work pretty well as long as you limit operations that are kind of meaningless and disable features like symlinks.

Mounting hierarchical data as a pseudo file system is actually pretty common. EG procfs, devfs, sysfs are all pseudo file system that present structured data to applications on Linux through the guise of a file tree.

[xyheme]

JSON is there for human to read a record of data by group.

I think it is only good to use directory as data table to store JSON data files, but not for JSON data properties.

[duped]

> JSON is there for human to read a record of data by group.

That's what tree is for

> I think it is only good to use directory as data table to store JSON data files, but not for JSON data properties.

I see that as no better than one big JSON file or a normal NoSQL database.

If you're really fancy then the whole DB is just a VFS and those JSON files aren't real files, just a serialized form of the DB.

[xyheme]

directory tree is not as easy to view and edit as JSON.

One big JSON file is harder.

I am not fancy, and the aim is to simply use file system as database.

Not fancy stuff like "database as file system as database".

[duped]

> directory tree is not as easy to view and edit as JSON.

    tree path/to
    cat path/to/key
    echo "1" > path/to/key

But my point is that you're not using the file system as a database. You're using it as an index, and haven't considered about multiple readers/writers to those individual JSON files that are doing the real work as databases. It's kind of like writing JSON into a SQL table. You can do it, but probably not to store important data within that JSON that always needs to be queried and ser/deserialized for any kind of read or write. If you need that, you probably want NoSQL.