On Tue, 2005-08-23 at 16:26 -0400, Tres Seaver wrote:

> Note that RDBMS-based applicattions will *already* impose such a
> requirement, from the moment that you want to join results from the RDF
> query to those from any other tables:  every non-toy RDBMS in existence
> has a "preferred primary key" type, which is an integer, for precisely
> the same reasons (to allow efficent joins).

Good point.

> RDBMS best practices insist that "normal" tables have a primary key of
> that type, whose value is supposed to remain invisible (or at least
> opaque) to humans.
> If we want to allow for scalable use of rdflib, I would guess we need to
> "promote" the integer ID from "implementation detail" to a first-class
> API citizen.

Well that's pretty convincing for me.  I'll wait for Dan to weigh in on

> They are know, but they are an *infeasible* join key (not only are they
> strings, but as arbitrary-length strings with common prefixes, their
> sorting semantics are almost worst-case for many join algorithms.)

Right, perhaps a good compromise is a URI utility which maps the URIs to
efficient join keys.  That adds a double layer of mapping, but for now
that might be an easy choice to make to give us time to think about
exposing a primary key.


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to