[development] relationships API vs i18n

[Robert Douglass]

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.

-Robert




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.
>
> -Arnab
>
>
>>
>> -- 
>> Dries Buytaert  ::  http://www.buytaert.net/
>>
>>
>
>