I was thinking about some stuff lately and I was wondering what would be the RIGHT way to do something like the following scenario (I’m sure it is a quite common thing for DB guys to do something like it).
Let’s say you have a products table, something like this (MySQL):
CREATE TABLE `products` ( `id` int(11) NOT NULL auto_increment, `product_name` varchar(255) default NULL, `product_description` text, KEY `id` (`id`), KEY `product_name` (`product_name`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; Nothing out of the ordinary here. Now lets say that there are a hierarchy of categories in a different table, and there is a separate table which binds many-to-many relationships with products table – so that each product belongs to some kind of a category (I’ll omit those, because thats not the issue here).
Now comes the interesting part – what IF each of the categories mandates additional set of variables to the product items. For example products in the computer monitors category must have LCD/CRT enum field, screen size enum etc. – and some other category, lets say ice creams have some other variables like flavor varchar, shelf storage time int etc.
The problem herein lies in that all products have a common set of variables (id, name, description and sort of like that), but there are additional variables which are not consistent from category to category – but all products should share common set, because in the end they all belong to the products group, so one can query for example SELECT * FROM products ORDER BY company_id (trivial example, maybe not representative, but you get the picture).
Now, I see severa potential resolutions:
– generate separate table for each product category and store products there with appropriate additional variables – stupid and not query friendly
– product table stays the same with common variables, and for each category create a separate table with additional variables binding two tables with a JOIN – normalized, but query performance and clarity issues – how would one filter down products from category (1st table – products) and additional filter for extra variable (17′ LCD monitors ie.) – it would require SQL JOIN trickery
– products table stays the same and add another variable type text that holds for example JSON data that hold additional variables – compact and neat, but can’t filter through variables with SQL
I know I’m missing something quite obvious and simple here – I’m a bit rusty on the normalization techniques 🙂
edit: I’ve been searching around stackoverflow before asking this question without success. However, after I’ve posted the question I have clicked on one of my tags ‘normalization’ and found several similar questions which resulted in to look up ‘generalization specialization relational design’. Point of the story is that this must be the first occurrence in my internet life that tags are actually useful in search. However, I would still like to hear from you guys and your opinions.
edit2: The problem with approach no.2 is that I expect somewhere around ~1000 specializations. There is a hierarchy (1-4 level deep) of categories and end nodes add specialized variables – they accumulate in the order of ~1000, so it would be a bit unpractical to add specialized tables to join with.
edit3: Due to the vast number of attribute volatility in my case ‘entity attribute value’ that was suggested looks like the way to go. Here comes query nightmares! Thanks guys.
How many product types do you expect? Do they each have their own application logic?
You can do a generalized model called the ‘entity attribute value’ model, but it has a LOT of pitfalls when you’re trying to deal with specific properties of a product. Simple search queries turn into real nightmares at times. The basic idea is that you have a table that holds the product ID, property name (or ID into a properties table), and the value. You can also add in tables to hold templates for each product type. So one set of tables would tell you for any given product what properties it can have (possibly along with valid value ranges) and another set of tables would tell you for any individual product what the values are.
I would caution strongly against using this model though, since it seems like a really slick idea until you have to actually implement it.
If you number of product types is reasonably limited, I’d go with your second solution – one main product table with base attributes and then additional tables for each specific type of product.