How to model the products table for an e-commerce?

1

I'm having a question about how to model the Produto table of a small e-commerce I'm doing. I've been seeing some e-commerces and I came across the following situation: mm same product can have different colors and sizes, so when the customer chooses the product in a different color the system pulls the same product but with different color and size available, being so apparently the product is registered more than 1x with the same name, but different colors and sizes, even because the product code is always different, that is, the same product can have several different codes, sizes, colors but the name is always the same, and I believe this is the cat's leap, correct me if I'm wrong.

Following this logic, I'm trying to model my Produto class in this way, but I came across a deadlock in inventory because the product can have the same name, different codes, different colors, different sizes, but manage inventory from the size becomes a bit complicated, because the same product can have different sizes in the stock and at the time of giving the output of the stock I need to rely on this situation. So I wanted to know the best way to do this?

Product table.

[Serializable]
public class Produto{

    public virtual long id                                      { get; set; }
    public virtual String descricao                             { get; set; }
    public virtual String descDetalhada                         { get; set; }    
    public virtual Subcategoria subcategoria                    { get; set; }
    public virtual IList<Cor> cores                             { get; set; }
    public virtual IList<Tamanho> tamanhos                      { get; set; }
    public virtual int qtdEstoque                               { get; set; }
    public virtual decimal precoAntigo                           { get; set; }
    public virtual decimal precoReal                             { get; set; }
    public virtual int status                                   { get; set; }

    public Produto(){
        cores = new List<Cor>();
        tamanhos = new List<Tamanho>();
    }
    public override string ToString(){
        return descricao;
    }

}
    
asked by anonymous 23.08.2017 / 14:28

2 answers

4

I'll start by saying you're still far from having an ideal template, for example using double to store price is wrong . Creating exercise software is easy, creating a real one is much more difficult, you will come across a lot of unexpected situation. It's enough to be a paradox because to begin with, you need to conceptualize everything right, even more that you do not have the experience to do everything you need, but without experience you can not conceptualize right.

One way is to actually have different products. It's simple at one tricky point in another. You need to see how you're going to want to work on it. I prefer the most conceptually right way, that is, you have a product with SKUs, one in the table has the product register and the other has the register of variations.

The product has all the general characteristics of the product and this is used to present. In the SKU tables you have inventory control effectively because you have to control each variation. Note that if some SKU is priced differently, you usually have a different product. But the decision may be a bit more complicated. It has a case that it may be useful to have a third table for groups of SKUs. Or it may be that each SKU has a different price, so it may be that the price may already be in the SKU. Or you might even consider that each SKU is a different product.

It's even more complicated because it has products that fit one model and other products fit into another model.

If you are doing something without knowing the model, you have to leave it as open as possible, to take care of all situations. And deal with these issues in code. Flexible applications are more complicated to develop.

If you know the model, you need to analyze the need. From what I read, but it may be wrong it seems to me that having a 1: N ratio in a product table SKU X seems appropriate. So it will work with single product but varying stock control.

It may be the case to start simple and then rethink this difficulty, until you have more input to make a decision. This is important because you are struggling in much more basic decisions. Start on the foundation, leave the finishing for later.

You can also ask a more specific question here when you have something closer to the need.

    
23.08.2017 / 14:47
2

Your problem is not modeling a table, but you do not know the business you are creating. Talk more with your P.O. or your customer about all processes.

Just to clarify a little:

Product , also known as Template or PartNumber is where the features will look. This guy has Versions , with simple changing features - like color, for example. Then you have the Inventory , where it says how much each Model / Version you have.

Learn more about the business before starting your system, and read about Code First strategies before "modeling table" strategies. Repository and persistence should be the developer's last concerns.

    
23.08.2017 / 14:35