Model Relational database with SKU

It seems appropriate, but it may not be. You are the person who most knows the real problem and has doubts, imagine we have no idea where that will be used, in what way, what the needs of today and tomorrow.

What I mean is that so much can go wrong or change, so random people on the internet are less able to say if everything is going to work out for you. You have to do your best and be prepared for possible changes. Do nothing that makes it difficult to change later. This is very rare to see, there lies the real problem.

Actually I have a lot of doubts if you need all this. It seems to me that some of these tables actually have a 1: 1 ratio and in that case I do not see much advantage being in a separate table. For me the tables linked to the SKU should be simple columns in the table itself, even after the comment below I see no reason for these tables to exist. I would probably simplify eliminating 5 tables. But who am I to say what I should do, it may still be that I have something that I do not know, so it is difficult to answer.

I even have doubts about whether there should be a separation between product and SKU. I even see some usefulness, but it may not be necessary. Many systems have what it would be just the SKU, after all if each SKU is different, it is another product.

I find it odd that it has a relationship with the product and SKU, that seems like an error.

I will not even mention confusing names, that's the taste. Not everything should be produto_tamanho , this is a problem that goes beyond modeling, that is, this is such a problem that doing so any modeling will "serve". This kind of thing will make future changes difficult. But I imagine that what will make it more difficult nor can you see in this model.

If the question had been placed as text and not as an image I would have rephrased the template and posted it here as I would.

The model you have done must meet the current needs of your project, you should not worry so much about what might happen in the future, the most important thing is that it meets the needs of now and has a well-connected structure. The more abstract, and the simpler, the better. However, this should not be confused with missing parameters or tables. One way you can do to build a database in a nice way: think of setting up a company with offices, departments, where you have to create each sector, and each with its own responsibility, now think how they should communicate with each other. From this abstraction, it is easier to understand how entities and their relationships will work. What to come in the future, you implement later.

Note: Just remembering that what you're doing is basically rewriting the wheel, since there are ready-made templates of cms that have well-crafted structures for product databases. Like virtual stores: OsCommerce , WooCommerce , Magento , etc.

In addition, other models , / a> that you can rely on, to study yours that are already ready. Just do a little research on the Internet for MER, DER, ER. Here other examples.