3 ms·

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 relationshi

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 3y ago
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-advantages-of-btrfs-for-end-users https://unix.stackexchange.com/questions/18388/what-are-the-...
- warrenm 3y ago
  I didn't realize btrfs was still around I haven't seen anything but ext4 or xfs in over a decade
  - xyheme 3y ago
    Me and a lot of linux user friends are using btrfs.
    - warrenm 3y ago
      cool nice to know it still exists :)
jqpabc123 3y ago
... 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.

xyheme 3y ago

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-advantages-of-btrfs-for-end-users https://unix.stackexchange.com/questions/18388/what-are-the-...

warrenm 3y ago
I didn't realize btrfs was still around I haven't seen anything but ext4 or xfs in over a decade
- xyheme 3y ago
  Me and a lot of linux user friends are using btrfs.
  - warrenm 3y ago
    cool nice to know it still exists :)

jqpabc123 3y ago

... 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.