On Sat, Sep 13, 2014 at 11:01 AM, James K. Lowden <jklow...@schemamania.org> wrote:
> I used "database" because that was his word. Whether or not a > filesystem is a database depends on the definition. I would say that > the files are data, but the filesystem is not a DBMS, partly for > reasons you mention. Do the files nonetheless constitute a database? > I would say no, because they don't meet that treshhold. Among other > things, the filesystem offers no key: no way to identify the entities > it stores. I say that a filesystem is an eventually-consistent key/value database. The keys are the filenames and the values are all big BLOBs, specifically the file content. Filesystems also have a hierarchical keyspace, which is an extension from the usual key/value concept, but it is still key/value. If your definition of "database" requires secondary keys, then lots of things that go by the name "database" do not qualify. Do you not consider GDBM to be a database engine? And yet it has only primary keys and values, just like a filesystem. This idea of viewing a filesystem as a key/value database is developed further in http://www.sqlite.org/affcase1.html and http://www.sqlite.org/appfileformat.html "Git" is a classic example of using a filesystem as a database. The repository history is stored in a "database" called ".git". Compare this with Monotone or Fossil which store the repository history in a relational database. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
