MySQL tables for node relationships - mysql

Question

I'm trying to figure out what would be the optimal database and table structure to store relationships between nodes of the type (var)char. I've last used MySQL many years ago as a backend for some simple PHP webpages and never got beyond that. I hope some seasoned users can give me their opinion.
Let's say I have a bunch of names:
Thomas
Jane
Felix
Marc
Anne
I now want to store their relationships. My idea is to have two tables that might look like this:
names (id, name) relationships (id_1, id_2)
0 Thomas 0 1
1 Jane 0 3
2 Felix 1 2
3 Marc 3 4
4 Anne ...
...
The scope of the data is as follows:
Table 'names' will contain approx. 5 million rows.
Table 'relationships' will contain 150-200 million rows.
The database will only be accessed by me, locally (server and client are the same machine)
I don't need responsiveness as with a web server, only a high throughput during the few occasions when I access it (to reduce waiting time)
My questions are:
I recall proper use of PRIMARY_KEY being important. I vaguely remember there being the possibility to assign the key to two columns (i.e. id_1, id_2 in my case); this helps querying I imagine?
Is there a way from within MySQL to prevent the creation of duplicate relationships (e.g. 0:4 & 4:0) during insertion?
MySQL defaults to InnoDB for me. Is this the database you would recommend for my scenario?
Any pointers welcome. Thank you.

Answer 1

Firstly, you need to consider whether your relationships have a "direction" associated with them. For example, the relationship "is a child of" has the opposite direction to the otherwise identical relationship "is a parent of"; on the other hand, the relationship "is a sibling of" is undirected (or bidirectional, depending on one's point of view).
The structure you describe is perfect for directed relationships.
Bidirectional relationships, on the other hand, are often best represented by deliberately performing the duplication described in your second bulletpoint; whilst this consumes more storage, it greatly simplifies queries such as "find all siblings of X"—which might otherwise have to take the union of two separate queries:
SELECT id_2 FROM my_table WHERE id_1=X
UNION
SELECT id_1 FROM my_table WHERE id_2=X
Because there is no index on the resulting column, these sorts of queries can be quite slow if one wants to do something more with the result (such as sort by id, or join with thenames table—albeit in that particular case one could perform the joins before the union, but that just increases redundancy and complexity in one's data manipulation code).
One can use triggers to ensure that whenever a relationship is written (inserted, updated or deleted) to a table that represents bidirectional relationships, the same operation is automatically performed on the reverse relationship.
Secondly, the representation you describe is known as an "adjacency list", which is very simple and easy to understand. But it's not great at dealing with deep searches through the data hierarchy, especially on MySQL (which, unlike some other RDBMS, doesn't support recursive functions). Thus finding "all descendants of X" or "all ancestors of Y" is actually quite difficult. Other data models, such as "nested sets" or "transitive closure" are much better for these tasks.
With that preamble said, on to your questions:
I recall proper use of PRIMARY_KEY being important. I vaguely remember there being the possibility to assign the key to two columns (i.e. id_1, id_2 in my case); this helps querying I imagine?
There are four possible primary keys for your relationship table:
(id_1)
(id_2)
(id_1, id_2)
(id_2, id_1)
By definition, a primary key must be unique within your table. Indeed it is the primary means of identifying a record. But if desired one can also define further UNIQUE keys, which have the same constraining effect as a primary key (the differences are relatively minor and beyond the scope of this answer): thus one can actually enforce any combination of the above constraints.
The above constraints would respectively: limit each name to being on one side of the relationship no more than once; limit each name to being on the other side of the relationship no more than once; and the final two limit each combination of names to being within the same relationship no more than once (the difference is merely the order in which the index is stored). If the table represents undirected relationships, then obviously the second and fourth constraints are semantically equivalent to the first and third constraints respectively.
Some examples:
if your table represents "id_1 is the genetic father of id_2" then id_1 might have many children. So (id_1) cannot be the primary key, as it won't uniquely identify records of fathers who have more than one child. On the other hand id_2 can only have a single genetic father (embryological advances aside), so (id_2) will uniquely identify a record and can be the primary key (that said, many-to-one relationships of this sort might as well be modelled via a father_id column in the names table). The other two (composite) keys would permit children to have many fathers and must therefore be incorrect.
if your table represents "id_1 is a parent of id_2" then both a parent can have many children and children can have more than one parent (this is known as a many-to-many relationship). Therefore the first two constraints are incorrect and one must choose between the latter two (as mentioned previously, the difference is merely the order in which the index is stored—so MySQL must locate the first column before it can lookup the second). Incidentally, in this case one might consider adding an additional column to the relationship table that indicates which parent the relationship represents; if a child can only have one parent of each type, then one could define the primary key as (child_id, parent_type).
if your table represents "id_1 and id_2 are married" then both (id_1) and (id_2) are "candidate keys", because noone can be married to more than one other person (at least in the UK, polygamy aside). Thus one might define (id_1) as the primary key and define a second UNIQUE key over (id_2). As mentioned before, one may well wish to place the records inside the table both ways around—and these constraints will not prevent that.
Is there a way from within MySQL to prevent the creation of duplicate relationships (e.g. 0:4 & 4:0) during insertion?
Yes, one can do so with triggers: but note what was been said above regarding bidirectional relationships (where such "duplicates" are often desired). An example of trigger that would enforce this type of constraint might be:
CREATE TRIGGER rel_ins BEFORE INSERT ON relationships FOR EACH ROW
IF EXISTS (
SELECT * FROM relationships WHERE id_1=NEW.id_2 AND id_2=NEW.id_1
) THEN
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = 'Reverse relationship already exists';
END IF;;
One may also want a similar trigger "before update".
A situation where a constraint of this sort might be desirable would be where the table represents "is a parent of", since a parent cannot be their child's child (however, in this case it may be worth noting that in such a relationship table, one may actually wish to go further and prevent all circularities—e.g. prevent a child from being the parent of their grandparent). Again, "adjacency list" is not the best model for enforcing this sort of constraint—"nested sets", on the other hand, entirely prevent all circularities purely by virtue of their structure.
MySQL defaults to InnoDB for me. Is this the database you would recommend for my scenario?
The biggest advantage of InnoDB is that it is fully ACID compliant, and thus offers transactional support. This is especially useful if you might write to the database from multiple places at one time. If you're simply going to perform a one-time-load of a bunch of static data into the database for subsequent querying, it may well be a little slower than MyISAM.