views:

19

answers:

1

I'm adding tags to several models (Posts, Articles, Photos, etc). I'm aware of rails tagging plugins but prefer not to use them, as they don't quite meet my specific needs.

I know the typical way of implementing polymorphic tagging support is to use 2 tables Tags, Taggings and setup the appropriate has_many :through relationships.

But, as I think about it a bit more - and here is my question: Is there a need for a Tags table. Are there any disadvantages of using just a Taggings table and have my relationships like this:

Post, Article, Photo
has_many :taggings

Taggings (attributes)
taggable_type
taggable_id
tag_name

Then I would just need to manage inserting/deleting taggings myself. Basically, I'd like to just store the tag_name attribute directly in the Taggings table instead of a Tags table.

The advantages are that eliminate managing a table, no joins to get the tag names (although I'll be doing a lot of SELECT DISTINCTs).

Could you let me know your thoughts on this design?

Thanks.

A: 

Those SELECT DISTINCTs are going to be one disadvantage. You're going to find it slow to build a list of tags, not just in the case of building an index to link (which you could work around by fragment caching, I suppose) but also for auto-complete.

I'd say the more significant disadvantage is that if you're using an in-application search solution (e.g. Xapian) you'll either need to index the Taggings table, which is likely to create some odd results, or not index tags at all, which might defeat the point of tags, depending on how you're using them.

None of which is to say you absolutely shouldn't do this, of course; skipping the extra join is going to make some things a lot faster. It's smart of you to look at the cost and decide if it's worth it.

pjmorse