best small database?

[Blair P. Houghton]

Larry Bates wrote:
> The filesystem is almost always the
> most efficient place to store files, not as blobs in a
> database.

I could get all theoretical about why that's not so in most cases,
but there are plenty of cases where it is so (especially when the
person doing the DB doesn't get the idea behind all filesystems,
which is that they are themselves simplified databases), so
I won't*.

In this case, the filesystem may be the best place to
do the work, because it's the cheapest to implement
and maintain.

--Blair

* - okay, I will

1.  Since the filesystem is a database, making accesses
to it after being directed there by a database means you're
using two database systems (and an intervening operating
system)  to do one thing.  Serious databases work from
disks with no filesystem to get rid of that extra layer entirely.
But there are benefits to having things in files reachable by
ordinary tools, and to having the OS mediating access to
the data, but you need to be sure you need those benefits
and can afford the overhead.  Academic in most cases,
including the one that started this thread.

2.  When using the filesystem as the database
you only get one kind of native association, and have to
use semantics in the directory and filenames to give you
hints as to the type stored at a particular location.  You get a
few pieces of accounting data (mod times, etc.) in the
directory listing, but can't associate anything else with
the file directly, at least not unless you create another
file that has the associated data in it, or stuff the extra
data in the file itself, but then that makes each file
a database...see where it goes?  Sometimes it's better
to come up with a schema you can extend rationally to
fit the problem you are trying to solve.

--Blair