One thing which has been going through my mind about this subject is
that the process has already happened in the evolution of database
systems.

In the beginning was the hierarchical database - all the data arranged
in a tree so that each item of data had a single parent. Blindingly
fast, but complex to maintain, and inflexible. I think that IBM's IMS
is the only surviving example - but it's still widely used.

Then came network databases - extend the hierarchical model so that a
node can have more than one parent. Increases the flexibility whilst
maintaining the speed of access - but enormously increases the
complexity and maintenance. Difficult to find any extant examples: the
model was developed by the CODASYL task group in the late 1960s, and
the main result was IDMS.

Then Edward Codd developed the relational database model: any data item
could be related to any other by a shared attribute/value. Infinitely
flexible - but so resource-heavy that at first it was thought to be
impractical. However, with the rapid development of faster hardware,
this was found not to be the case, and now the relational database has
eclipsed the previous database types, to the point that one hardly ever
hears about them.

ISTM that what we're thinking towards is an analogue of the relational
database applied to files. With extended attributes and metadata, we're
effectively at the "network database model" stage. So the question
would appear to be: how to replicate the evolution of the relational
model from the network one in terms of files and filesystems. (And -
it's such an obvious thought-thread that it seems self-evident that it
must have already been done by someone somewhere.)

One of the best summaries of the database models that I've yet seen is
on the MariaDB site: three articles, one each for the three models,
starting with this one:

https://mariadb.com/docs/general-resources/database-theory/understanding-the-hierarchical-database-model


On Mon, 2026-06-15 at 16:17 +0200, Didier Kryn via Dng wrote:
>      Indeed extended user attributes can be used to handle key/value
> pairs.
>
>      I have just experimentd it with command-line tools setfattr and
> getfattr (I needed to install package attr)
>
>      The attributes are preserved when you move the file (mv) even
> across filesystems, provided they both support the extended user
> attributes. I moved files between reiserfs and ext4 for the test. But
> attributes are not copied by cp. Note that rsync has the option -X or
> --xattr to preserve them.
>
>      Note that the attribute name must be specified as user.name.
>
>      Note also that the mount manual for ext4 is wrong: it says the
> option is ext_attr, when it is actually user_xattr (like for
> reiserfs).
>
>      There remains to build tools to search files according to the
> attribute's value and measure their performance. It reminds me that
> search method alternatives to path name were at the heart of the work
> of
> Hans Reiser. Next, one needs to define one's personal policy to sort
> files, ie keynames and values, and enforce setting them...
>
>      I'm not familiar enough with the find utility to know if it can
> select files by their extended attributes.
>
>      This doesn't invalidate the utility of directories in any way.
>
> --     Didier
>
> _______________________________________________
> Dng mailing list
> Dng@???
> Manage your subscription:
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> Archive: https://lists.dyne.org/lurker/list/dng.en.html