Question

Can anyone explain, how products with modification can be stored in database.
For example:

• USB Flash Memory

  • 2Gb
    • red (price 9,90, available 10)
    • black (price 9,90, available 4)
    • white (price 9,90, available 30)
  • 4Gb
    • red (price 15,90, available 5)
    • black (price 15,90, available 1)
  • 8Gb
    • red (price 20,90, available 10)

• Car Chevrolet Cruze

  • уear 2010

    • gearbox ‘manual’, engine ‘gasoline 1.8L’, color ‘gray’, price: 20k, available : 10
    • gearbox ‘manual’, engine ‘gasoline 1.8L’, color ‘gray’
    • gearbox ‘auto’, engine ‘disel 2.0L’, color ‘white’

  • year 2011

    • gearbox ‘manual’, engine ‘gasoline 1.6L’, color ‘red’
    • gearbox ‘manual’, engine ‘gasoline 1.6L’, color ‘black’
    • gearbox ‘auto’, engine ‘disel 2.0L’, color ‘white’
      etc.

Any product may have many modifications of many features.
How can it be stored in relational db? EAV?

Answer 1

Well, without knowing what you are going to do with the data it is difficult to anwer.

But assuming you want to cover a world of unlimited product types and features, the best is probably to have a completely generic “type-value” table.

So:

Table: PRODUCTS (all common product features)

Table: FEATURE (name, comment, etc)

Table: FEATURE-PER-PRODUCT (fk to product, fk to feature, value of feature, date-modified)

You could enahnce the feature-per-product with strong typed values and the type in feature.

You could also consider not having the feature table and just use a string in feature-per-product

update:
I would go for minimum amount of data in the product and as many features separate. You can always reconstuct (flash 2gb red) from three features, but the other way is much harder. The tradeoff is more data and bigger queries but with decent indexes and perhaps some views with clustered indexes that can be handled

So my advice is the product is Flash USB and color and gigabytes are features