如何将产品的修改存储在数据库中?
谁能解释一下,经过修改的产品如何存储在数据库中。
例如:
USB 闪存
- 2GB
- 红色(价格 9.90,可用 10)
- 黑色(价格 9.90,有 4 件)
- 白色(价格 9.90,可用 30)
- 4GB
- 红色(价格 15.90,可用 5)
- 黑色(价格 15.90,可用 1)
- 8Gb
- 红色(价格20.90,可用10)
- 2GB
汽车雪佛兰科鲁兹
2010 年
- 变速箱“手动”,发动机“汽油 1.8L”,颜色“灰色”,价格:20k,可用数量:10
- 变速箱“手动”,发动机“汽油 1.8L”,颜色“灰色”
- 变速箱“汽车”,发动机“disel 2.0L”,颜色“白色”
2011 年
- 变速箱“手动”,发动机“汽油 1.6L”,颜色“红色”
- 变速箱“手动”,发动机“汽油 1.6L”,颜色“黑色”
- 变速箱“auto”,发动机“disel 2.0L”,颜色“white” 等等
任何产品都可能有许多功能的许多修改。 如何将其存储在关系数据库中? EAV?
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)
- 2Gb
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?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
好吧,如果不知道你将如何处理这些数据,就很难回答。
但假设您想要涵盖无限产品类型和功能的世界,最好的方法可能是拥有一个完全通用的“类型-值”表。
因此:
表:产品(所有常见产品功能)
表:功能(名称、评论等)
表:每个产品的功能(fk 到产品、fk 到功能、功能值、修改日期)
您可以增强该功能- 每个产品具有强类型值和特征类型。
您还可以考虑不使用功能表,而只在每个产品的功能中使用字符串
更新:
我会追求产品中最少的数据量和尽可能多的功能分离。您始终可以从三个功能重建(闪烁 2GB 红色),但另一种方法要困难得多。权衡是更多的数据和更大的查询,但具有不错的索引,也许还有一些带有可以处理的聚集索引的视图
所以我的建议是产品是闪存USB,颜色和千兆字节是功能
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