[VoodooJuJu]

For simple apps and app components, it's very convenient and manageable.

It becomes a problem when you: (1) scale up (2) have to deal with multiple relationships between objects. The "Database design" by Adrienne Watt posted in another comment covers the scale concerns well, but another scale problem she doesn't mention is hitting inode limit, at least if you're on a single machine. You can of course use a distributed filesystem as database, but at that point, you might want to use a database proper.

[xyheme]

Inode limits depends on the file system you use.

I am using Btrfs.

Btrfs inode limits is in a whole different league (whereas ext4's inodes are allocated at filesystem creation time and cannot be resized after creation, typically at 1-2 million, with a hard limit of 4 billion, btrfs's inodes are dynamically allocated as needed, and the hard limit is 2^64, around 18.4 quintillion.

> -- https://unix.stackexchange.com/questions/18388/what-are-the-...

[warrenm]

I didn't realize btrfs was still around

I haven't seen anything but ext4 or xfs in over a decade

[xyheme]

Me and a lot of linux user friends are using btrfs.

[warrenm]

cool

nice to know it still exists :)

[jqpabc123]

... hitting inode limit

Use a better file system with the ability to "scale up".

Attempting to predict and limit the max. number of allowed files at the time of creation is an unbelievably audacious yet hamstrung and self limiting design --- one that is totally unnecessary and as you point out, doomed to fail at some point --- often before storage and address space are depleted.

I find this particularly egregious in an era of constantly increasing storage demands, changing volume capacities and drive pooling in an OS often promoted for it's server prowess and flexibility.