[development] relationships API vs i18n
rob at robshouse.net
Fri Nov 10 12:36:33 UTC 2006
The last few posts to this thread assume that we need to generalize the
API *and* generalize the storage table. A lightweight triples API could
take a table name as a starting parameter (with a sensible default, of
course), and then modules like the buddylist could add their own triple
table but still use the API.
So before we start pouring cement around our database foundation, lets
try to identify the types of functions we want in the API. Aside from
putting triples into the database and getting them out again, what
would, say i18n need?
Furthermore, every ambitious developer under the sun has taken a stab at
this already (dikini, vauxia, eaton, myself, dmann, jaza...), so what
have we learned from it?
And finally, it would be silly to talk about this without asking what
role chx's tree API might play. Triples can result in trees, too, after all.
Arnab Nandi wrote:
> On 11/10/06, Dries Buytaert <dries.buytaert at gmail.com> wrote:
>> Having simple, specialized
>> tables (like the one above) is anything but a bad thing, IMO.
> I completely agree with this; there is a tradeoff in keeping
> specialized tables for high-volume tasks(e.g. taxonomy); and
> low-volume, high variablity tasks("related to", "books", etc). But we
> should not forget the latter case. For the latter case, having a new
> table for each of these relationships (most of which are custom ones
> anyway) is fairly overkill (since there will be ~10-20 tuples per
> table, then).
> The concept of relations is used for everything that's not high
> volume, and does not deserve a special table. Think of it as a
> "catchall" for all relations that are not treated specially.
>> Dries Buytaert :: http://www.buytaert.net/
More information about the development