Skip to content

Instantly share code, notes, and snippets.

@gavinlaking
Created August 5, 2012 17:30
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save gavinlaking/3266142 to your computer and use it in GitHub Desktop.
Save gavinlaking/3266142 to your computer and use it in GitHub Desktop.
Filesystem as databases?

If we should store assets on the filesystem rather than in the database because access is faster, then why are we not storing data on the filesystem rather than in a database? A database typically consists of a couple of files, one being the hunk of data itself, the others, supporting files like indicies.

So, why not use the filesystem as it was designed: direct and flexible. Store our data using the right tool for the job; individual files storing discrete pieces of information. I can't think of anything that an off-the-shelf database ACIDically provides that our filesystems can not already do.

Consistency may be lacking, from the respects of ensuring that a file is as it says (size, contents, etc), however, is it not the job of those wishing to store data to ensure it is correct before persistence? i.e garbage in, garbage out.

What are your thoughts?

@brianloweongit
Copy link

Microsoft had the notion way back with development proposals for Win2000 to replace the traditional FAT or FAT32 or NTFS filesystem with a managed data store resembling SQL_Server, so the view you got of your hard disk in tools like Windows Explorer or file dialogs would be complete fiction - even more so than it is with FAT. The premise was that everything you save to your hard disk goes through some interface anyway, and SQL_Server was supposed to be the most efficient way to determine where on the platter to store bits and blobs.

The idea was dropped from Win2K because it wasn't ready in time for the launch, and it never made it in to any later version, perhaps because some forward thinkers could see the coming of cloud storage or because hard disk technology moved on quickly enough to remove the perceived bottleneck of the filesystem interface, or maybe they just decided the world wasn't ready to buy in to replacing a simple file allocation table with a complex DBMS.

I'm not sure your suggestion of going the whole opposite direction would work either though. DBMS are evolved to be efficient at storing, searching and retrieving portions from absolutely specified data structures. Your suggestion seems to discard all that evolution and require app developers to reinvent wheels to manage an interface between their data and the file allocation table.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment