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 it. > 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. -Michel _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com