Why you don't need a tag system in 99% of cases
Situation: you are managing your own product. For a certain model you need a category.
Your developer suggests using a tagging system.
It’ll be more flexible and future-proof. Also it’s easy to include.
You know tags from twitter and are about to agree to go along with it.
But: is it really a good idea?
After reading this post you know exactly how tag systems operate, when to use them, and when to say “No” to an overly eager developer.
- It’s easy to get started with a tag system
- Tag systems make a database model harder to query
- If you only want categories, use enums
The client wants to categorize
I’m writing this post because my team just ran into the issue with a customer project.
Situation: we have an
Event and a
Participation model. The client’s Product Owner wants to sort events into 4 categories. Participations should get separated into 6 different categories.
Our initial thought: it’d be great to attach a tag to each event. If we keep tags generic, we can then also attach
How do tags work?
It uses a new model with a polymorphic association. That way it can attach to any model.
Querying will be harder
event.tag_names => ['demo']
Event.tagged_with(:names => ['demo'], :match => :any)
Alternative: Why not just categories?
These are categories but they look like tags:
With Hotwire, this is super easy to build:
The determining factor: multiple or not? Free definition or not?
Rule of thumb: In order to use tags, you need these things to be true
- use tags when you to attach 0 or many pieces of information to a record.
- And be able to define them totally freely
Agile approach: quick now, upgrade later
- We’ll upgrade once the client wants to add more information to events+participations