标记数据库的关系数据的优势

Question

Imagine a simple database (MySQL) with objects, and tags that could be attached to the objects. What are the advantages of storing the tags in a seperate table (so you have the tables tag, object, tag_has_object) over making two tables (tag and object, where tags are not saved as number but directly as a string).

While I'm used to making everything relational, someone proposed doing it the second way (two tables), and I can't come up with any counter arguments. Is there an advantage of one over the other?

Answer 1

The main difference is how you intend to use it.

Tags as strings:

• Easy to insert
• Might end up with slow select queries
• Will use more data

Tags as table:

• More difficult inserts
• Faster select queries
• Will use less data

So if your app will not be very big there is not problem using strings.

Answer 2

The three table option implies there is a pre-defined list of tags which you associate with objects. The two table option implies the tag is free-text and could be any value.

Whether, in the three table option, you choose to add an additional surrogate numeric key to the tags table and use this a reference in the linking table, or use the tag itself as the key and reference this is a pragmatic choice based on the criteria of familiarity, irreducibility, stability and simplicity. Considering all of these you would need to decide whether a surrogate key is suitable in your specific situation.

Some things to consider

With only a natural key of the tag itself.

• Do not need to join to tags table to get tag value (familiarity)
• One, single column candidate key on the tags table (simplicity)

With an additional surrogate key:

• Changes to a tag do not need to be cascaded to the referencing columns (stability)

Answer 3

It's worth thinking about the ways in which you will use the data.

The obvious scenarios are:

• insert a new object, and associate it with tags. Much easier with two tables, as long as you don't care about validation (is "article" the same as "Article"? Might "articel" a typo?), or whether the tag already exists.
• show all objects matching a given tag. Much easier (and probably faster) with 3 tables, because you're only going to be comparing strings on the "tag" table, and then joining on keys (presumably integers). This is especially important if you support wild cards or other "search" like features.
• show a "tag cloud". A little easier (and probably faster) using 3 tables - again down to the string manipulation you may have to do.

In general, I'd accept a little extra pain when inserting the record for fast retrieval, because in most applications, you do more reads than writes.