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@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/