There’s been much discussion over the past few months about the marriage of databases and filesystems – with Microsoft’s Longhorn reportedly sporting the
Yukon integrated SQL Server, and GNOME Storage in heaty debate, if not development, there’s been lots to talk about.But it’s worth bearing in mind that “Database Filesystems” are not a new idea – in fact, they’ve been in widespread use for many years. For a prime
example, one need look no further than to IBM – their OS/400 operating system, which runs on the iSeries (previously known as the AS/400) minicomputers, features what can best be described as a “DB2 filesystem”.
To those used to DOS or UNIX, the OS/400 filesystem is a little strange. Instead of directories, there are libraries – and libraries cannot contain other libraries – and within those libraries are files. Unlike files in the UNIX world, files under OS/400 are heavily structured.
An OS/400 file can contain any number of members – each having an identical structure. Traditionally, you would group related members of the same type
into a single file; for example, the C source files for a program might be grouped together into a single file. In fact, you can think of an OS/400 file as a collection of database tables all sharing the same definition – because for many purposes they are exactly that.
That might sound strange – and you might well wonder how C source code can be stored in rows and columns – wouldn’t that be horribly complicated? In reality,
it’s very simple; C source code on the iSeries has three ‘fields’ – the line number, the date and time it was last modified, and the text of the line itself – and each ‘row’ is a line of the source code.
This probaby seems like quite an inefficient way of storing C source code – and you could be right – although it makes writing an editor a little easier!
But think about this: if every file has a structure akin to a database table – and can be treated like a database table – and you can still read and write to the members as easily as you can read and write to a file under UNIX or Windows, you have an immensely powerful system.
Under this system, the need for custom file formats vanishes; you just store your data as you would logically store it in a database table. And of course,
getting information out again is no more difficult than performing a query.
If you’re a typical user (if there is such a thing), you might be wondering what the big deal is – and you’d be right to. The implementation of file
storage isn’t something users should normally ever have to worry about – and the big deal is that you probably do have to worry about it from time
to time, and anything that means you have to do that less often is probably a good thing.
If you’re a developer, I’m hoping that you can see the possibilities of such a system. There’s often occasions where using a database for storage would be
really useful – but requiring MySQL or Postgres, or even just an ODBC connection, is just too heavyweight for your utility or application. After all, if Epiphany required a database connection in order to store its preferences, people would soon complain; but if the database was the filesystem, Epiphany could just create a file structured as name and value pairs and use that.
The OS/400 way of doing things is just one implementation – and in a way, the Be Filesystem was another. WinFS and GNOME Storage will add two more, and
nobody really knows quite how they’re going to shape up yet, but if they come anywhere close to the power and flexibility of OS/400’s storage system,
they’ll be worth taking a careful look at.