How to store these field descriptions in mysql?

Apologize for the long topic, I didn't intend for it to be this long, but it's a pretty simple issue I've been having. :)

Let's say you have a simple table called tags that has columns tag_id and tag. The tag_id is simply an auto increment column and the tag is the title of the tag. If I need to add a description field, that would be around 1-2 paragraphs on average (max around 3-4 paragraphs probably), should I simply add a description field to the table or should I create a new table called tag_descriptions and store the descriptions with the tag_id?

I remember reading that it is better to do this because if you do a query that doesn't select the description, that description field will still slow down mysql. Is this true? I don't even remember where I read that from, but I've been kind of following it for a couple years now... Finally I question if I need to do this, I have a feeling I don't. You'd also need to inner join whenever you need the description field.

Another question I have is, is it generally bad to create new tables that will only hold very few rows at the max? What if this data doesn't fit anywhere else?

I have a simple case below which relates to these two questions.

I have three tables content, tags, and content_tags that make up a many to many relationship:

content

• content_id
• region (enum column with about 6-7 different values and most likely won't grow later on)

tags

• tag_id
• tag

content_tags

• content_id
• tag_id

I want to store a description around 1-2 paragraphs for each tag, but also for each region. I'm wondering what would be the best way to do this?

Option A:

• Just add a description column to the tags table
• Create a new table for region_descriptions

Option B:

• Create a new table called descriptions with fields: id, description, and type
• The id would be id of the content or id of the enum field
• The type would be whether it is a tag description, or region description (Would use the enum column for this)

Maybe have a primary key on the id and type?

Option C:

• Create a new table for tag_descriptions
• Create a new table for region_descriptions

Option A seems to be a good choice if adding the description column doesn't slow down mysql select queries that don't need the description.

Assuming the description column would slow down mysql, option B might be a good cho开发者_如何学Cice. It also removes the need for a small table with just 6-7 rows that would hold the region descriptions. Although now that I think of it, would it be slow to connect to this table if originally to get a region description you'd only need to go through very little rows.

Option C would be ideal if the description columns would slow down mysql and if a small table like region descriptions would not matter.

Maybe none of these options are the best, feel free to offer another option. Thanks.

P.S. What would be an ideal column type to use to hold data that usually 1-2 paragraphs, but might be a little more sometimes?

I don't think it really matters if you don't handle thousands of queries per minute. If you are going to have a zillion queries per minute, then I would implement the various options and perform benchmarks for all these options. Based on the results, you can make a decision.

In my (admittedly somewhat uninformed) opinion, it really depends on how much you'll be using both of them.

If properly indexed, that JOIN should not be very expensive. Also, a larger table will be slower. It inhibits caching, and takes longer to access stuff, although indexing seriously mitigates this problem.

If you'll be joining tag names to tag IDs a LOT, and only rarely will be using the descriptions, I'd say go with separate tables. If you'll be using the descriptions more often, go with one table.

For the first part of your question: if you have a tag with an id, a name and a description, you should save it in 1 table.

Now, this query

 SELECT name FROM tags WHERE id = 1;

will NOT slow down if you have 1, 2 or 20 extra fields in there.