On 6/21/2011 11:38 AM, Max OrHai wrote:
There are certainly practical differences between "conventional"
relational databases and hierarchical filesystems, without having to
get into implementation details. I'm sure at least a few people on
this list are familiar with the BeOS filesystem, which acted much more
like a relational DBMS than most filesystems do... over a decade
later, we've now got hacked-on DBMS-like functionality in the form of
(e.g.) Spotlight, but most users are stuck with the little walled-off
databases presented by their media library and email application
software. Once again, it's not a technical issue so much as a matter
of perspective.
http://www.theregister.co.uk/2002/03/29/windows_on_a_database_sliced/
granted, I wasn't thinking strictly RDBs (Relational Databases), but was
including several other types of database as well. RDBs can be
considered a subset of databases as a whole, which include potentially
other ways of representing data. granted, yes, many people hear
"database" and assume it is an RDB in question...
not read whole article yes, but was looking at it some.
may read the rest later...
possible, relatively simple: table-files...
in this way, the file is simply a table, rather than the whole database,
and may be accessed independently of some overarching DBMS.
then, one puts a few tables in a directory, and maybe has some
command-line driven database tools, allowing them to dispense with SQL,
and doing SQL-like operations directly from the shell...
"dbselect --cols=foo,bar,baz --from=tableA,tableB --where=..."
with the ability potentially to redirect query output to another file, ...
then, one can do SQL-like stuff directly from shell scripts or similar.
maybe also partly useful would also be a database API which allows
lower-level access to the database, namely the ability to work more
directly with the tables (get/set rows, ...), and potentially implement
ones' own query mechanics if so desired, rather than the usual thing of
feeding in globs of SQL and processing the results post-hoc (the whole
sort of "one row at a time force-fed into ones' app" interface).
if everything is done well, it could reduce the awkwardness of trying to
use RDBs from programs.
if I wanted, I could add tables to my HDB system, effectively
resurrecting an idea of mine from long ago (the years known as
high-school): a Heirarchical-Relational Database.
basically, the notion being that it is a little silly at present that
one can either have a hierarchy or tables but not both. in this system,
it would have been a hierarchy of tables.
if done well though, either putting tables into files, or dropping
tables into an HDB, could achieve a similar effect (a table would be
sort of like a normal key/value node, except that each value is
array-like). the other possibility is an array of nodes.
array-of-structs-with-annotations is possibly a reasonable tradeoff.
another past considered idea was the idea of using type-driven
schema-optimization for nodes (in general), where in my HDB the
node-type (held in the default/"_" key) is used, well, as a node type.
in the case of table rows, the node-type could indicate the table
header, allowing rows to be compacted into structs.
note that at present no such optimizations are done in-general, as nodes
are generally simply key/value pairs...
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
