1

I have a Product entity:

public class Product
{
    public int Id { get; set; }
    public string? Name { get; set; }
    public string? Description { get; set; }    

    [ForeignKey("Brand")]
    public int BrandId { get; set; }
    public Brand? Brand { get; set; }
    public List<ProductVariation>? ProductVariations { get; set; } = new();
}

... and it's variations:

public class ProductVariation
{
    public int Id {get;set;}
    public string? SKU { get; set; } 
    public string? Label { get; set; } 
    public string? Description { get; set; } 

    [ForeignKey("Product")]
    public int ProductId { get; set; }
    public required Product Product { get; set;}

    public int StockQuantity { get; set; }
    public double Price { get; set; }
}

For products with different variations, this model would probably be ok for my needs. However, what if there are items that either does not have a variation and/or the user chooses to save the product name with the variation values instead of creating a variation for the product. E.g. "Evian Water 500ml" instead of creating a product with a name "Evian" then defining an attribute of "Weight" as "500ml"?

My question is: Is my model ok for no-variation products in a way that I save the Product Name to Products table and Price, StockQuantity etc to a different table? Or should I have the main Products entity contain Price, StockQuantity etc fields and variations table should only be used for products that actually has variations?

Thanks

1
  • 2
    I believe the traditional retail term you're after here is "variant" rather than "variation", and it's likely a really important distinction in terms of modelling. From a retail perspective, all tangible products are variants, including unique products (so unique products are simply products with a single variant) Jan 12, 2023 at 11:50

2 Answers 2

1

You are on the right track. But reverse your thinking.

The primary thing is the SKU. That's the real product. Then you have the "How am I presenting groups of related SKUs to the customer?" object.

Your no variation product is as SKU

Your products with variations are multiple SKUs

You have some admin interface where some catalogue creator selects ten sizes x 5 colours of SKUs and groups them as Product : "Summer Dress". But maybe the red SKUs are in a separate grouping "Party Dress" or whatever. Its up to your marketing.

Pricing is harder because maybe the skus have different prices, or maybe not, maybe its a sale etc so you need a function rather than a simple price col in your database.

0

When there is no compelling technical reason (like performance or storage restrictions) to store data in a non-uniform, unnormalized way, I would usually stick to a normalized model and uniform model.

If you would have the Price, for examples, in both entities, how would you interpret it if a Product entity comes along with exact one ProductVariation entity with a different price? Or are you going to replicate all attributes from ProductVariation inside Product, and when you have N ProductVariation entities, will you interpret it always as a representation of N+1 variations? Technically, this would be possible, but it would not be uniform any more: you would always have to treat the "first" variation in code or queries different from any further variation.

So if you prefer a solution which can be maintained more easily, avoid to replicate domain attributes over different tables if you don't have to.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.