Question

I’ve got two tables…

Table “tags”

+---------+----------+
|  tag    |   id     |
+---------+----------+
|  nancy  |   902    |
+---------+----------+
|  fred   |   903    |
+---------+----------+
|  suzan  |   904    |
+---------+----------+
|  joe    |   905    |
+---------+----------+

and table tag to tag

+---------+----------+
|  tag_a  |   tag_b  |
+---------+----------+
|  903    |   902    |
+---------+----------+
|  905    |   903    |
+---------+----------+
|  902    |   904    |
+---------+----------+
|  904    |   905    |
+---------+----------+

I often scan the tag to tag relationships using an INNER JOIN statement with the “tag” table so that I can query who is related to “nancy”. I’m wondering how much better off I would have been better off just dumping the name of the tag into the tag to tag table rather than joining the tag table so that I can look for relationships based on the tag name. Is JOINING the table a huge performance hit? My tag to tag table is in the 900k row range. The tag table is around 30k.

Answer 1

If you wish to store any meta-information about the tag, then you’ll need a tag table anyway. Adding a join does potentially increase the expense of the query a good deal.

In your case, I recommend you consider the following:

1. Use InnoDB
2. Change id to TagString
3. Place the actual tag in TagString
4. Create a foreign key to the Tag table, with cascading update/delete

In this way, you can group, filter, etc… on a single column, but if you need more info, you can join over to the Tag table (or whatever tables you need).

I ran into some serious performance problems with MySQL when we hit 80,000,000 tag records and were doing live joins to generate tag clouds on http://tagcloud.com … Some caching really helped that, but still, it seemed like it was pushing the design limits of a relational database (in the normal form). We would have been better off to use a different storage format that may be more expensive to write to, but faster to read from.