实体属性值数据库与严格关系模型电子商务 [英] Entity Attribute Value Database vs. strict Relational Model Ecommerce
问题描述
可以肯定地说， EAV / CR 数据库模型是坏。也就是说，
问题：应使用什么数据库模型，技术或模式来处理描述电子商务产品的属性的类在运行时改变？
在一个好的电子商务数据库中，您将存储各种选项（如电视分辨率，但下一个产品可能不是电视，没有电视分辨率）。如何存储它们，有效地搜索，并允许您的用户使用描述其产品的变量字段来设置产品类型？如果搜索引擎发现客户通常根据控制台深度搜索电视，您可以向字段添加控制台深度，然后在运行时为每个电视产品类型添加单个深度。
好的电子商务应用程序之间有一个很好的共同特征，它们显示一组产品，然后有向下钻取侧边菜单，您可以在其中看到电视分辨率作为标题，而前五个最常见电视分辨率找到的集合。您点击一个，它只显示该分辨率的电视，允许您通过选择侧面菜单上的其他类别进一步向下钻取。这些选项是在运行时添加的动态产品属性。</ p>
进一步讨论：
这么长的故事短，在互联网上有任何链接或模型描述，可以在学术上修复以下设置？我感谢Noel Kennedy建议类别表，但需要大于。我在下面用不同的方法描述它，试图突出重要性。我可能需要一个视点校正来解决问题，或者我可能需要更深入到EAV / CR。
爱上对EAV / CR模型的积极反应。我的同事开发人员都说，Jeffrey Kemp在下面谈到：新实体必须由专业人员建模和设计（从上下文中读取，阅读他的回答如下）。问题是：
- 实体每周添加和删除属性
（搜索关键字指明未来的属性） - 新实体每周到达
客户希望向产品添加属性因为两个原因：
- 部门/关键字搜索/类似产品之间的比较图
属性必须具有重要性，而不仅仅是关键字搜索。如果他们想要比较所有有奶油结霜的蛋糕，他们可以点击蛋糕，点击生日主题，点击奶油糖霜，然后检查所有有趣的蛋糕，知道他们都已经鞭打奶油结霜。这不是蛋糕特有的，只是一个例子。
我可以想到一些一般的利弊，
ul>
？ ）
报告
不可能
<大数据集性能不佳
选项2：分别为每个实体建模：
- Con：需要更多时间来收集
需求和设计 - Con：新实体必须建模，
由专业人士设计 - Con：每个
实体的自定义界面组件 - Pro：数据类型约束和验证实现
- Pro：SQL易于编写，易于
理解和调试 - Pro：即使最复杂的报表都相对简单
- Pro：大数据集的最佳性能
选项3，组合模型实体，但为某些/所有实体的自定义属性添加扩展）
- 需要更多的时间来收集需求和设计，而不是选项1，但可能没有选项2 *
- Con：新实体必须由专业人士建模和设计 $ b $
- Con：只要报表中包含任何自定义属性，SQL就会变得复杂。 li>
- Con：一般来说效果良好，除非您开始需要按照自定义属性进行搜索或报告。
我不确定选项3是否会在设计阶段保存任何时间。并尽可能避免EAV。然而，对于一些情况，用户需要EAV附带的灵活性;但这带来了巨大的成本。
It is safe to say that the EAV/CR database model is bad. That said,
Question: What database model, technique, or pattern should be used to deal with "classes" of attributes describing e-commerce products which can be changed at run time?
In a good E-commerce database, you will store classes of options (like TV resolution then have a resolution for each TV, but the next product may not be a TV and not have "TV resolution"). How do you store them, search efficiently, and allow your users to setup product types with variable fields describing their products? If the search engine finds that customers typically search for TVs based on console depth, you could add console depth to your fields, then add a single depth for each tv product type at run time.
There is a nice common feature among good e-commerce apps where they show a set of products, then have "drill down" side menus where you can see "TV Resolution" as a header, and the top five most common TV Resolutions for the found set. You click one and it only shows TVs of that resolution, allowing you to further drill down by selecting other categories on the side menu. These options would be the dynamic product attributes added at run time.
Further discussion:
So long story short, are there any links out on the Internet or model descriptions that could "academically" fix the following setup? I thank Noel Kennedy for suggesting a category table, but the need may be greater than that. I describe it a different way below, trying to highlight the significance. I may need a viewpoint correction to solve the problem, or I may need to go deeper in to the EAV/CR.
Love the positive response to the EAV/CR model. My fellow developers all say what Jeffrey Kemp touched on below: "new entities must be modeled and designed by a professional" (taken out of context, read his response below). The problem is:
- entities add and remove attributes weekly
(search keywords dictate future attributes) - new entities arrive weekly
(products are assembled from parts) - old entities go away weekly
(archived, less popular, seasonal)
The customer wants to add attributes to the products for two reasons:
- department / keyword search / comparison chart between like products
- consumer product configuration before checkout
The attributes must have significance, not just a keyword search. If they want to compare all cakes that have a "whipped cream frosting", they can click cakes, click birthday theme, click whipped cream frosting, then check all cakes that are interesting knowing they all have whipped cream frosting. This is not specific to cakes, just an example.
There's a few general pros and cons I can think of, there are situations where one is better than the other:
Option 1, EAV Model:
- Pro: less time to design and develop a simple application
- Pro: new entities easy to add (might even be added by users?)
- Pro: "generic" interface components
- Con: complex code required to validate simple data types
- Con: much more complex SQL for simple reports
- Con: complex reports can become almost impossible
- Con: poor performance for large data sets
Option 2, Modelling each entity separately:
- Con: more time required to gather requirements and design
- Con: new entities must be modelled and designed by a professional
- Con: custom interface components for each entity
- Pro: data type constraints and validation simple to implement
- Pro: SQL is easy to write, easy to understand and debug
- Pro: even the most complex reports are relatively simple
- Pro: best performance for large data sets
Option 3, Combination (model entities "properly", but add "extensions" for custom attributes for some/all entities)
- Pro/Con: more time required to gather requirements and design than option 1 but perhaps not as much as option 2 *
- Con: new entities must be modelled and designed by a professional
- Pro: new attributes might be easily added later on
- Con: complex code required to validate simple data types (for the custom attributes)
- Con: custom interface components still required, but generic interface components may be possible for the custom attributes
- Con: SQL becomes complex as soon as any custom attribute is included in a report
- Con: good performance generally, unless you start need to search by or report by the custom attributes
* I'm not sure if Option 3 would necessarily save any time in the design phase.
Personally I would lean toward option 2, and avoid EAV wherever possible. However, for some scenarios the users need the flexibility that comes with EAV; but this comes with a great cost.
这篇关于实体属性值数据库与严格关系模型电子商务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
