Re: key and value
Filesystems should all be databases. Microsoft really cowered out on that one, we never did see "WinFS".
Configuration should all be databases (registry, INI files, etc.).
Applications should be a bottled container consisting of a database and a program.
And databases should be an internal, core, OS function (why is something like SQL not built-into the machine as an OS-level thing?)
Everything is storing data, in an ordered fashion, and needs to be queried. Why they aren't all just databases stored "however" (in "files", in a flat table, direct in an key-store, it matters not if you only interact with the database interface instead of the underlying format), I've never understood.
Exchange / email is just a big database. SQL is the core of every business. Almost all websites have underlying DB structures. Even WSUS and Windows updates are databases internally, not to mention file search. Most web browsers even store history, cache, etc. in databases (e.g. sqlite).
And when can I start "tagging" files on my filesystem rather than stupid tree hierarchies? That file is simultaneously "2017", "Project X" and "Junk", so there's no way to organise it in a tree that shows me all three sensibly.
Perfectly suited to a database - files are all listed in one huge table, and have an index number. Tags are another table. Each file contains a list of tags that it uses (either directly, or via a mapping via another table with a row for each mapping - "FILE 146475 TAG 587453987, FILE 146475 TAG 264763, FILE 146475 TAG 1237", etc..).
Optimise the SQL and the core database enough, and it'll be insta-search, multi-tag, etc. and you can still just store the file at whatever index you want on the actual disk format. Hell, technically even the file table for fragmentation etc. is just another database.
Biting the hand that feeds IT
