I'm designing a system where items can have tags, which is easy enough. The problem is we also need items to have arbitrary attributes. For example, an item could have an attribute called "Length" with the number value of 10. Another item could have no "Length" attribute. This is to allow users to search for all things in the database that have a length of 10, for example.

Does it make sense to integrate these arbitrary attributes with the tags? A design like that would allow some tags to have values, and other tags to have no values. Or should I separate the two, and have normal tags, as well as attributes?

I'm not clear on the terminology, what is this arbitrary attribute design called?


1 Answer 1


I think it might be better to keep tags and attributes separate. Attributes are usually name/value pairs and are often (in my experience) typed so that you can't enter the weight of a product as "blue".

Tags are just words associated with a product, such as the tags "morning", "caffeine", "I_need_it_bad!" which might go with a coffee maker.

Here's an example data schema:

  - id (PK)
  - name

  - id (PK)
  - type (Could be "NUMBER", "STRING", or FK to a special "types" table)
  - name ("length", "weight", "zodiac sign", etc...)

  - id (PK)
  - item_id (FK to items.id)
  - item_attribute_id (FK to items_attributes.id)
  - value (such as "4 m", "3.4 kg", "Scorpio", etc...)

  - id (PK)
  - name (any tag name)

  - id (PK)
  - tag_id (FK to tag_names.id)
  - item_id (FK to Items.id)

This design allows you to associate any Item_Attribute with any Item. It lets you specify a type, though you'll have to enforce that somewhere else (in your front-end, in your back-end, heck you could even try in INSERT/UPDATE triggers). It also allows more free-form tags to be applied to items.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.