We've spent a lot of time thinking about file system front ends for databases (mostly in the context of pq, but not entirely). I'm unconvinced that this model of representation really adds much for most databases.
The problem is that the application talking to the database still has to know too much about the representation, making it fairly static. This isn't inherently a problem, really, but it isn't anything resembling a relational (or, since pq was mentioned, implicit relational) database. One could certainly do an on-the-fly generated namespace in response to each query. That'd be neat for interactive use, but, again, any real application using it would have to already know a lot about the structure of what it's getting back. Given that, getting the database out of a file tree isn't really a win over getting it out of a tab-separated text line (or whatever your DB gives you). Two related things I think *are* more interesting. First, I've often found it useful to have a "middleman" application turning a more general backing store into a more structured file tree. This is, for example, how Inferno's styx-on-a-brick demo worked: each layer in the stack provided a different file tree with more structure imposed (okay, it was a short stack). This allows you to avoid stuffing too many of the specifics into what should be more general. Second, and really more simply, we've found it useful to have a channel to the database present in the file system. Eliminate any network programming from your apps, and if the app providing the channel does a good job, you get a set of benifits more or less for free (or at least for aggregated cost). Anthony
