[development] relationships API vs i18n

[Gabor Hojtsy]

On Fri, 10 Nov 2006, Jeremy Epstein wrote:

> It would be good to support relations between entities of any type,
> not just nodes. So instead, we could have:
>
> CREATE TABLE relation (
> type char(12),
> id1 int,
> type1 char(12),
> id2 int,
> type2 char(12),
> weight int
> );
>
> I also give my +1 to a lightweight triple-based relationship API in
> core. I know that dman (author of the relationships / RDF module) has
> been putting a lot of work into this stuff, although he has expressed
> concern that his module is currently too heavy for most simple uses.
> It would be great if we could get a super-light version of his API
> into core.

Question is if the above is enough lightweight. Scanning for integers in a 
table are the quickest method to grab some record. Question is what type 
of stuff do we want to have relations with. Eventually everything becomes 
a node as it seems from ongoing development :) :) See profile nodes, 
category module for taxonomy as nodes and such. Well, OK we are not there 
yet, so we need relations between different type of stuff.

Maybe if we need to sacrifice some design perfectness for speed, we can 
do:

CRATE TABLE relation_nid_nid (
   id1 INT,
   id2 INT,
   type varchar,
   weight INT
)

CREATE TABLE relation_nid_tid (
   id1 INT,
   id2 INT,
   type varchar,
   weight INT
)

...

The same column names are to ease(?) SQL selection. You can also represent 
tid->nid relations by a reverse relation type in the same table. This 
design does not allow for querying all stuff that relates to a node at 
once, but is a lot quicker for situations when you only need to find some 
particular type of entities related to nodes (like taxonomy items, other 
nodes, users, etc).

This would be rather limiting since the created tables would define the 
possible relation types. If there is no tid_uid table, then you cant have 
that relation.

Note that I am just bringing up this because we need to keep performance 
in mind. Maybe this is a horrible idea (and I certainly see some of its 
week points), but it might energize some discussion in this field.

Gabor