[REBOL] [DEV] Re: dbms3.r 01
From: g:santilli:tiscalinet:it at: 13-Jan-2002 19:57
Hello Joel!
On 13-Gen-02, you wrote:
JN> At the same time, it takes real courage to expose one's
JN> thinking in near-real-time to an audience or a group of
JN> collaborators. I applaud your bravery!
Well, I hope you will all be indulgent to me. :)
JN> My experience suggests that there's value in three kinds of
JN> access to elements of a collection, which I'll call by
JN> semi-arbitrary names for this discussion:
JN> 1) "physical" access -- corresponding to your notion of
JN> "row-ID"
JN> in which traversal of a collection is done in the fastest
JN> possible manner -- SINGLE VALUED.
This is the case for the low-level functions.
JN> 2) "identity" access -- via a unique ID which is guaranteed
JN> not to change throughout the lifetime of the collection
JN> (a
JN> sort of "true name" of each entity) allowing references
JN> to
JN> entities in the collection to remain valid even if the
JN> order
JN> or structure changes -- SINGLE VALUED.
This is why I used them in dbms.r; but now I'd like to abstract
more and let the user decide the keys for a table. Anyway, as
things proceed, I might decide to include some kind of special key
to optimize speed.
JN> 3) "criteria-based" access -- via a search expression, which
JN> may refer to one or more attributes of an entity,
JN> possibly
JN> represented as a function passed to an iterator which
JN> finds
JN> and presents all entities possessing the specified
JN> property(ies)
JN> -- SINGLE OR MULTIPLE VALUED.
This is what the user sees, even in the current dbms.r.
JN> I'd suggest that "row-ID" be as thoroughly hidden as
JN> possible, e.g., only used within a loop that is scanning the
The plan is that it will be used in indices only, internally. If a
row gets moved for some reason, the index can be updated; of
course I think such change will not be very frequent, but mainly
originating from an optimization of the table or something like
that...
JN> Just my $0.015 of the moment ;-)
Thanks! They are much appreciated. :)
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
