Forum OpenACS Q&A: User-user relationships, rather than user-group relationships

Collapse
1: User-user relationships, rather than user-group relationships
Posted by Reuven Lerner on 06/24/02 10:33 AM
(Boy, I'm just full of questions this morning...)

It's pretty clear to me how I can create a membership or composition
relationship between a user (or person) and a group, or between two
groups.  But I have a few clients now who want to have an established
relationship between two users -- that is, they want to indicate that
the two users are married, and have the ability to handle cases of
death or divorce.

My initial thought was to create a new table that will simply allow me
to keep track of the various person_ids.  But I'm sure that I'm not
the only one out there who wants to handle such a case -- and it seems
to fall through the cracks of the group API, which doesn't seem
equipped to handle relationships between two individuals.

I'm similarly going to have to deal with relationships between users
who are parents and children.

Should I just go it alone, or is there some sort of relationship
possibility among users, as well?

Collapse
2: Response to User-user relationships, rather than user-group relationships (response to 1)
Posted by Pascal Scheffers on 06/27/02 03:52 PM
For my 3.2.5 project I am recording study subject and their relations, for this I created three tables 'parties' and two subclasses 'persons' and 'institutions', parties can be related to each other in any which way.

I have a contacts table with 'party_id' and 'related_id' and a relation 'type'. Relation types can be 'directional' or not: you can have a parent-child relation that states who is parent and who is child, but also a 'partner' type, which is unidirectional. Types and their directionality and between which party types they can be created are in a table as well.

Directionality has some consequences for queries, but I do not see a way around them: to find all contact records for a person you need to search in both 'party_id' and 'related_id' columns. Not too bad when you are just looking at one party, but becomes quite inefficient when you want to build a tree view of relationships in the system (family tree and such).

I am also still tweaking a good UI for making relations, using the contacts table to type-cast parties by leaving the 'related_id' NULL.

I also use this system to keep track of foreign database unique IDs to link systems together. In all, it works rather nicely for me and would be trivial to adapt to user records in 3.2.5. You can have the code and datamodel, if you want.