Linked by Thom Holwerda on Mon 30th Jan 2012 20:39 UTC
General Unix Finally something really interesting to talk about. If you've used UNIX or any of its derivatives, you've probably wondered why there's /bin, /sbin, /usr/bin, /usr/sbin in the file system. You may even have a rationalisation for the existence of each and every one of these directories. The thing is, though - all these rationalisations were thought up after these directories were created. As it turns out, the real reasoning is pretty damn straightforward.
Permalink for comment 505548
To read all comments associated with this story, please click here.
RE[3]: We are stuck in the past.
by jabjoe on Wed 1st Feb 2012 22:13 UTC in reply to "RE[2]: We are stuck in the past."
jabjoe
Member since:
2009-05-06

It's not. Files are unstructured binary blobs. There is no way to query what's inside them.


What info exactly do you expect to be able to query from a jpeg or mp3? Only meta-data will have anything meaningful for a query, and yes, that sort of data, makes sense in a database and often is put there. But its also embedded in the file as its tiny and that ensures it stays with the file.

You could view the filesystem as a database where the path system is the primary index. Find and Grep can be used, with others, to query. Ok, it's the command line not SQL, but I won't be surprised if someone has written something to do it with SQL. Indexing scales better than sequential scan and there are things to do exactly that for your files. But they are all in userland. The kernel need only provide the basics, the primary key and the data.


They are.

It's the wrong tool for the job. You don't store that in a database, you store it in a file on a filestore. Many database just aren't design for storing GBs in a column entry for a row. It's just not what they are for.

Reply Parent Score: 2