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

Asked

Viewed 593 times

0

I have a question about how to model the table Produto of a small e-commerce I’m doing. I have been seeing some e-commerces and 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 available size, thus, apparently the product is registered more than 1x with the same name, however, different colors and sizes, even pq the product code is always different, ie the same product can have several codes, sizes, different colors but the name is always the same, and I believe that this is the jump of the cat, correct me if I’m wrong.

Following this logic, I’m trying to model my class of Produto in this way, but I came across an impasse in the stock, because the product can have the same name, different codes, different colors, different sizes, but managing the stock from the size becomes kind of complicated, because the same product may have different sizes in stock and at the time to give the exit of the stock I need to rely on this situation. So I wanted to know the best way to do it?

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;
    }

}
  • Have any answers solved what was in doubt? Do you need something else to be improved? Do you think it is possible to accept it now?

2 answers

6

I’m going to start that is still far from having an ideal model, for example use double to store price is wrong. Creating an exercise software is easy, creating a real one is much harder, you will come across a lot of unexpected situation. It becomes a paradox because to start well you need to conceptualize everything right, even more that you do not have experience to do everything you need, but without experience you can not conceptualize right.

One way is to really have different products. It’s simple at one tricky point at another. You need to see how you want to work at presenting. I prefer the most conceptually certain form, IE, you have a product with Skus, in a tabla has the registration of the product and and another has the registration of variations.

The product has all the general characteristics of the product and this is used to present. In the Skus tables you have control of the stock effectively because you have to control each variation. Note that if any SKU has a different price, in general you have a different product. But the decision can be a little more complicated. There is a case where it may be useful to have a third table for groups of Skus. Or it may be that each SKU has a different price, then the price may already be in the SKU. Or you may even consider that each SKU is a different product.

It’s even more complicated because there are products that fit one model and other products fit another model.

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

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

Perhaps it is the case to start simple and then rethink this difficulty, until you have more subsidies to make a decision. This is important because you are struggling with much more basic decisions. Start with the foundation, save the finish for later.

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

  • well, from what I understand you say to create 2 tables, one of the product itself and the other of the SKU. I usually do so for PDV systems for markets, but in the case that I am doing I did not want anything so elaborate, even pq I will sell little thing. But blz, I get your point. Thank you.

  • Well, then you can do it the way you want, the question was about how to model properly. If you already have a vision of how to ask the question loses the sense. If you want a table makes a product by SKU.

  • In vdd my doubt was more about how to do the scheme of searching the product msm by different colors and different sizes, as I said I had already seen in some e-commerces, pq apparently they register the product several times with the name msm, however, different colors and sizes and how they manage the stock with so many nuances of the product msm based on size, but I understood your point, I will try to elaborate here. Thank you.

  • For me this is gambiarra, although it can be done. I prefer the most correct concept. I developed a famous ERP where they adopted this strategy from elsewhere in the system and until today it is only headache because of the wrong decision. But your case looks like it won’t have that much, just be aware that you might have problems. Just remembering that this error is small next to other errors that you can already see in this software.

2

Your problem isn’t modeling tables, but you don’t know the business you’re creating. Talk more to your P.O. or customer about all processes.

Just to clarify a little bit:

Product, also known as Model or Partnumber is where the characteristics will be. This guy has Versions, with simple features changing - like color, for example. Then vc has the Stockpile, where it says how much of each model/version you have.

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

  • The business is my own, I’m developing for a little shop I own, but I’ve never developed.

  • No, Fernando, the business is "shop". You’re just computerizing her business.

  • I understood your tip: You say to create 2 tables, 1 for basic product information and another for Stock, in the stock table I will set size, colors, etc..etc..etc. Well, I think that’s it, I do so in PDV systems, however, as the e-commerce I’m doing is relatively pqno thought in Fz tbm the simplest things. But I got your tip.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.