Database design for Tagging multiple types of entities

Question

I\'m currently designing a database schema that\'s used to store recipes. In this database there are different types of entities that I want to be able to tag (ingredients, reci

Answer 1

I have a similar 'problem' on my hands too. I am developing a small product database which involves tagging and also giving tags a value (tagname: color, value: green for example).

The two main tables are items (I) and articles (A). Items are actual physical items, and articles are derieved from items. Articles are something that can be displayed on a website, and items are the ones to be stored in a warehouse. A small example of this relationship could be car parts. A radiator with known dimensions and other data can actually fit many different models and makes, that's why the item used to respresent the radiator relates to multiple articles which indicate what the radiator can fit. On the other hand we might have two different radiators available for one model, one that is a factory-new version, and one that is just remanufactured. In such a case there are two items relating to the same article.

So, I and A have an N:M relationship.

Items and articles have certain properties. For instance the radiator item might have data like condition, material, weight, height, width and thickness. The article also has some basic information like make, model, year, engine etc, but might also need some special data like chassis model, transmission type, or something else like two different fitting types that have been used on the same model. Because two items can link to one article, it means i cant just tag articles. Tagging an article with both condition values is just stupid, on the other hand tagging one item with multiple instances of a model, make or some special requirement is also not a good idea. _there are two types of properties, the first indicate what something is like, and the second type indicates what it will fit.

Tags do not have to have a value, they can just simply act as a conventional tag that's assigned to an entity.

Radiators are just an example of a simple product. We might aswell put some computer parts or clothing in our database. This means that i need to be able to put different 'tags' on two different entities, I and A.

I need to be able to implement a search for articles in a webshop. Lets say i am using a tree-based navigation where i have a category called "Used nissan radiators". The search would involve searching both the articles and items, articles have the tag Model:Nissan, and items have the tag Condition:Used. Ofcourse when the user looks at the article he will indeed see all the items associated with the article.

One of the solutions i am pondering with is a triangle database design where is a common table called tags for all the properties and tags.

We have the tables items (I), articles (A) and tags (T) They are joined with N:M relationships: I2A joins the items to the articles. T2I joins the tags to the items and might store the value for the tag or property too. T2A joins the tags to the articles and might store a value for the tag too.

On paper, this 6-table design to tackle this problem looks quite nice, but i am getting a headache on forming a decent query where i can select the articles that match a set of different tags and their values, for example: Condition=Remanufactured, Make=Nissan

What i want to be able to do, is something like www.summitracing.com. Select Departments from the left below "Shop", the select any category and you'll see how they have managed to give items some properties. They have engine size for most applications, but when looking for rims, they also have a property for the width.

Any feedback on this would be greatly appreciated, im am starting to hit the dead trying to design this.