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).
> 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