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