[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: sql api for ufs
On 17/06/2010 5:55 AM, Louis Guillaume wrote:
On 6/12/10 8:09 AM, Carl Brewer wrote:
On 11/06/2010 8:07 AM, George Georgalis wrote:
...a glorious extension of the locate command, which has tools to
generate commands to manupalate the filesystem (local/remote) and
transfer over various protocols/auth. For the purpose of archiving
and indexing media across multiple devices.
Sounds a tiny bit like "Pick"
Wow! Now there's something I'd *never* have expected to see in a NetBSD
mailing list. :)
But it is true: a NF^2 (non first normal form) system would probably be
much faster for optimizing reads of this kind of data; the kind that's
in a UFS-like file system.
Each directory record would contain a list of record identifiers for the
contents. And each node (of any form) could have a pointer back to it's
This could be done using a key=>value type storage system (bdb or some
variant for example) where you have the list of children and the parent
as delimited fields in the value? Possibly other meta-data could be
stored in the database too.
Use the inode as the key, a field for the name, one for the list of
children's keys and one for the parent key. Then an index on the name
field to make lookups by name fast. I think that's how one would do it
in one of the "modern" Pick-type systems.
Library (as in books!) used Pick for a long time as their base for OPACs
and the like. I was exposed to this (as part of a move away from it!)
in the early 1990's. There are probably remnants of this technology in
many places you'd not expect. Library automation systems are one place
to look. In many ways Pick was a -long- way ahead of its time. For the
size of the database and the volume of queries it dealt with on pretty
limited hardware, Pick was very good indeed.
Some library automation systems moved away from the pure Pick systems
(like the McD-D systems we had) to Pick-on-UNIX which was probably
similar to what the OP is interested in.
Everything old is new again ...
Main Index |
Thread Index |