I'm solving problem, how to store products with its variants in database. My current system looks like this:
PARAMETERS - id_parameter (some parameter value - i.e. size XXL),...
PRODUCTS_PARAMTERS - id_product, id_paramter
CATEGORIES - id_category,...
PRODUCTS_CATEGORIES - id_product, id_category
FILES - id_file,...
PRODUCTS _FILES - id_file, id_product
PRODUCTS - id_product, description, price, vat, is_variant (1 or 0, if 1, product is variant), main_product(id is variant, here is stored main products id)
In this system, if product is not variant, it won't have filled just price. This system has pros, that I won't have to make so much edits in code and functions... cons are I think in size. Because there will be lots or rows - main products and variants, so query will need to check i.e. 10 000 rows...
Now, I was thinking about it a bit and I've got this idea: store main products and variants into separate tables. Then, I will need to edit mapping tables - I can add there column, where I will specify, if id_product is from products variants table or from main products tables. Or I will need to create other maping tables - in one maping table I will store paramters for main products and in the second one I will store parameters for products variants...
What do you think about this 2 solutions? Which one will be better? Most important for me is speed - especially when filtering products...
Thank you for your opinions or ideas, how to make it.
If several concepts are merged into a single table, it is generally not a good idea. If you have n products and m variants, then whenever you intend to filter only by products, your query will have to process n * m records. If they are separated, then this kind of query will search from only n records. Also, if you store the variant in description, then in case of a name change you will have to update the descriptions. Read about normal forms, they will greatly help you.