相关疑难解决方法(0)

可以肯定地说,EAV/CR数据库模型很糟糕.那说,

问题:应该使用什么数据库模型,技术或模式来处理描述可以在运行时更改的电子商务产品的属性的"类"？

在一个好的电子商务数据库中,您将存储选项类别(如电视分辨率,然后为每个电视分辨率,但下一个产品可能不是电视,没有"电视分辨率").如何存储它们,有效搜索,并允许用户使用描述其产品的可变字段设置产品类型？如果搜索引擎发现客户通常根据控制台深度搜索电视,则可以向字段添加控制台深度,然后在运行时为每种电视产品类型添加单个深度.

良好的电子商务应用程序中有一个很好的共同特征,它们显示一组产品,然后"向下钻取"侧面菜单,您可以看到"电视分辨率"作为标题,以及前五个最常见的电视分辨率发现集.您单击一个,它只显示该分辨率的电视,允许您通过选择侧面菜单上的其他类别进一步向下钻取.这些选项是运行时添加的动态产品属性.

进一步讨论:

长话短说,互联网上是否有任何链接或模型描述可以"学术上"修复以下设置？ 我感谢Noel Kennedy建议的类别表,但需要的可能还要大于此.我在下面用不同的方式描述它,试图强调其意义.我可能需要进行视点校正来解决问题,或者我可能需要深入了解EAV/CR.

喜欢对EAV/CR模型的积极响应.我的开发人员都说杰弗里·肯普在下面提到了什么:"新实体必须由专业人士建模和设计"(脱离背景,阅读下面的回复).问题是:

• 实体每周添加和删除属性
  (搜索关键字决定未来属性)
• 新实体每周到达
  (产品由零件组装)
• 旧实体每周都会消失
  (存档,不太受欢迎,季节性)

客户希望为产品添加属性有两个原因:

• 相似产品之间的部门/关键字搜索/比较图表
• 结账前的消费品配置

属性必须具有重要性,而不仅仅是关键字搜索.如果他们想要比较所有有"奶油糖霜"的蛋糕,他们可以点击蛋糕,点击生日主题,点击生奶油糖霜,然后检查所有有趣的蛋糕,知道他们都有奶油糖霜.这不仅仅是蛋糕,只是一个例子.

我正在与Magento做一些定制工作,Magento有一个基于EAV模型的数据库设计,我需要一些很好的资源/教程来解释EAV数据库模型.请不要将维基百科作为资源提供......我正在寻找能够以初学者友好的方式教授EAV的东西.

我想要创建数据库表,我可以在其中存储应用程序设置.两个表设计中哪一个更好:

1. 将设置存储在一列中,将一行存储为键 - 如下所示:

2. 仅将设置存储在两行中 - 如下所示:

哪两个更适合存储应用程序设置？

最好的祝愿

SQL中的Entity-Attribute-Value数据库设计的主要缺点似乎都与能够高效,快速地查询和报告数据有关.我读到的关于该主题的大部分信息都警告不要因为这些问题而实施EAV以及几乎所有应用程序的查询/报告的共性.

我目前正在设计一个系统,其中一个实体的字段在设计/编译时是未知的,并由系统的最终用户定义.EAV似乎非常适合这个要求,但由于我所读到的问题,我对实施它犹豫不决,因为这个系统也有一些非常繁重的报告要求.我想我已经找到了解决这个问题的方法,但是想向SO社区提出这个问题.

鉴于典型的规范化数据库(OLTP)仍然不总是运行报告的最佳选择,一个好的做法似乎是拥有一个"报告"数据库(OLAP),其中来自规范化数据库的数据被复制到,广泛索引,以及可能非规范化以便于查询.是否可以使用相同的想法来解决EAV设计的缺点？

我看到的主要缺点是将数据从EAV数据库传输到报告的复杂性增加,因为您可能最终必须在EAV数据库中定义新字段时更改报告数据库中的表.但这几乎是不可能的,并且似乎是EAV设计提高灵活性的可接受的权衡.如果我使用非SQL数据存储(即CouchDB或类似的)用于主数据存储,这种缺点也存在,因为所有标准报告工具都期望SQL后端进行查询.

如果您有一个单独的报告数据库用于查询,那么EAV系统的问题是否会消失？

编辑:感谢您的评论到目前为止.我正在研究的系统的一个重要事项是,我真的只是在谈论为其中一个实体使用EAV,而不是系统中的所有实体.

系统的全部要点是能够从多个不同的源提取数据,这些数据是提前未知的,并且会对数据进行处理以获得关于特定实体的一些"最知名"数据.因此,我正在处理的每个"领域"都是多值的,我还需要跟踪每个领域的历史记录.对于这种情况的标准化设计最终是每个字段1个表格,这使得查询它无论如何都很痛苦.

以下是我正在查看的表格模式和示例数据(显然与我正在处理的内容有所不同,但我认为它很好地说明了这一点):

EAV表

Person
-------------------
-  Id - Name      -
-------------------
- 123 - Joe Smith -
-------------------

Person_Value
-------------------------------------------------------------------
- PersonId - Source - Field       - Value         - EffectiveDate -
-------------------------------------------------------------------
-      123 -    CIA - HomeAddress - 123 Cherry Ln -    2010-03-26 -
-      123 -    DMV - HomeAddress - 561 Stoney Rd -    2010-02-15 -
-      123 -    FBI - HomeAddress - 676 Lancas Dr -    2010-03-01 -
------------------------------------------------------------------- …

我正在构建一个新系统，该系统将需要可扩展的数据模型。它非常复杂，但是需要这种结构的系统部分与电子商务系统的产品部分非常相关，因此我将以此为例。

想象一下一组公司。每家公司都有一系列的产品，其中有一些基本的属性，如name，sku，description，price等。除了这些基本属性，公司应该能够创建n定制的产品属性，属于公司（即美孚公司不应该能够看到Acme Inc.的自定义属性）。除此之外，每个公司都应该能够为每个产品转换这些属性；所以每个自定义属性值基本上从一个构造attribute，一个product，language和一个value。

我确实知道，如果您存储固定数量的属性，而需要扩展属性数量的不是系统所有者，则EAV结构是一种反模式。

所以我的问题是-您将如何实现？在这种情况下，EAV结构真的是反模式吗？Magento是使用这种设计的人的经典示例，似乎他们建立了一个怪物，不得不通过实现平面索引表来“修复”它。但是，是否还有其他数据库设计模式可以实现这种灵活性？