问题标签 [entity-attribute-value]

这是我多年来在多个地方看到的场景。我想知道是否有人遇到过比我更好的解决方案...

我的公司销售的产品数量相对较少，但我们销售的产品是高度专业化的（即，为了选择给定的产品，必须提供大量的详细信息）。问题在于，虽然选择给定产品所需的细节数量相对恒定，但所需的细节种类在产品之间却有很大差异。例如：

产品 X 可能具有识别特征，例如（假设地）

• '颜色'，
• '材料'
• “平均失败时间”

但产品 Y 可能具有特征

• '厚度'，
• '直径'
• '能量源'

创建一个同时使用产品 X 和产品 Y 的订单系统的问题（其中之一）是订单行必须在某些时候引用它“销售”的内容。由于产品 X 和产品 Y 是在两个不同的表中定义的 - 并且使用宽表方案对产品进行非规范化不是一种选择（产品定义非常深） - 很难找到一种明确的方法来定义订单行订单输入、编辑和报告的实用性。

我过去尝试过的事情

• 创建一个名为“产品”的父表，其中包含产品 X 和产品 Y 共有的列，然后使用“产品”作为 OrderLine 表的引用，并在产品 X 的表之间创建一个以“产品”作为主要侧的 FK 关系和产品 Y。这基本上将“产品”表作为 OrderLine 和所有不同产品表（例如产品 X 和 Y）的父级。它适用于订单输入，但会导致订单报告或编辑出现问题，因为“产品”记录必须跟踪它是什么类型的产品，以确定如何将“产品”加入其更详细的子产品、产品 X 或产品Y.优点：保留了关键关系。 缺点：在订单行/产品级别进行报告、编辑。
• 在订单行级别创建“产品类型”和“产品密钥”列，然后使用一些 CASE 逻辑或视图来确定该行所指的定制产品。这类似于第 (1) 项，但没有通用的“产品”表。我认为它是一个更“快速和肮脏”的解决方案，因为它完全消除了订单行及其产品定义之间的外键。优点：快速解决。 缺点：同第（1）项，加上丢失RI。
• 通过创建一个通用标题表并使用自定义属性的键/值对（OrderLine [n] <- [1] Product [1] <- [n] ProductAttribute）来同质化产品定义。 优点：保留关键关系；产品定义没有歧义。 缺点：报告（例如，检索带有属性的产品列表）、属性值的数据类型、性能（获取产品属性、插入或更新产品属性等）

如果其他人尝试了不同的策略并取得了更大的成功，我肯定想听听。

谢谢你。

在我参与的几个 Web 应用程序项目中，客户要求能够创建自己的表单。问题出现在如何存储他们的表单定义，然后如何将用户输入的值存储到这些自定义表单中。

我已经看到它做了两种方式：

1. 假设客户端只定义了多少个字段，以及与这些字段相关联的标签；我们可以得出一个涉及四个表的解决方案。 FormDefinition, FormFieldDefinition, FormInstances, FormFieldValues. FormDefinition客户端对and进行更改FormFieldDefinition，Web 应用程序使用该信息呈现 HTML Web 表单，网站访问者（最终用户）将在该表单上提交表单，其中FormInstances创建新行并将值保存在FormFieldValues桌子。

   行中的FormDefinition定义形式，即form definition ID = 2, form title = 'Car Registration Form'。中的行FormFieldDefinition定义表单中的字段FormDefinition，即field definition ID = 7, field label = 'Car Model', field type = 'varchar(50)'。Rows inFormInstance是用户填写的每个表单的一个实例，即definition id = 2, date_entered = '2008-09-24'. 中的行FormFieldValues是用户的条目，即field definition = 7, value = 'Tiburon'.

   不幸的是，这意味着其中的值列FormFieldValues必须是您的客户可能在 Web 表单中指定的最大可能大小的 char 类型......并且当表单定义更改时，管理旧数据变得不确定。但是用户条目是可查询的（我写了一个快速查询，列出了给定表单 id 的用户条目，这类似于另一个 pivot question）。

2. 使用四个表的替代方法是将表单定义和用户的表单条目序列化为 XML（或 YAML 或类似的东西）并将其存储为文本。好处是表格在数据库中是人类可读的。缺点是解析 XML 会产生更多的应用程序开销，并且从 SQL 的角度来看，数据库的可查询性会大大降低。

我真正的问题是，这个数据库模型叫什么？（所以我可以用谷歌搜索这个问题。）但我会选择一个答案：哪个是更好的实现，或者那里有更好的（或同样好的）实现？

有没有人在 SQL Server 中实现了一个非常大的 EAV 或开放模式样式数据库？我想知道这是否存在性能问题以及您如何克服这些障碍。

我有一些属于某个类别的产品。

每个类别可以有不同的属性。

例如，

• 类别汽车具有属性颜色，功率，...
• 类别宠物具有 重量，年龄，...

类别数约为 10-15。每个类别中的属性数量为 3-15。产品数量非常大。

这个应用程序的主要要求是非常好的搜索。我们将选择类别，并为该类别中的每个属性输入标准。

必须为这种情况设计数据库。(SQL Server 2005)

是否有适用于 PHP/MySQL 的实体属性值框架？我开始写我自己的，但我觉得它已经完成了。有什么建议么？

[原标题：有没有办法在基于标签的组织方法上强制建立关系结构？]

我有一些实体，它们有一系列属性。某些属性会影响实体可以具有的其他属性，许多属性被组织成组，并且有时实体需要具有来自某些组的特定数量的属性，或者可能具有来自某些组的一系列属性。

有没有办法使用数据库对这些标签到标签的关系进行建模，例如需求、分组、排除等，或者这只能通过编程的“业务规则”实现？理想情况下，我希望可能的标签及其关系易于配置，因此非常灵活。

我考虑的一种方法是拥有标签和可能的关系，然后你会得到一个标签-标签应用关系类型的表格，但这似乎是一种相当脆弱的方法。

那么，这是否可能以更严格的方式进行？如果可以，我将如何开始呢？

我正在研究用于分析已发布表单数据的星型模式。表单数据将发布到的站点实际上在托管表单的站点之外，因此只有表单中的数据可用。我将提供包含一些额外有用信息的选项，包括隐藏字段、原始推荐人、会话 ID 等。

我将能够使用正则表达式来匹配某些数据类型并将它们提取到特定维度，例如邮政编码。

我有一个解决维度的任意性质的解决方案，它不是一个很好的解决方案，但它会起作用。

我遇到的问题是我不知道我的事实表中会出现什么，它不像我可以聚合一个很好的数值。除了满足这些标准的“是的，有一个表单帖子”这一事实之外。

我想知道我是否以正确的方式处理这个问题？我是否使用了错误的工具来完成这项工作？还是我只是错过了什么？

西蒙。

更多细节：

有两个功能区域，根据标准过滤表单帖子，例如在两个时间戳之间。但就过滤而言，几乎所有东西都可以争夺。选定的表单帖子将用于生成 csv 文件以供导出。

另一个主要领域是分析，研究广告支出转化为客户线索是一个明显的起点。也有点开放式，取决于表单数据。

我有一个包含多个字段的 SQL 表

身份证 | 价值 | 类型

典型的记录可能是：- 1000,10,[int]

第二行可能是：-

1001，富，[字符串]

第三行可能是：-

1002,10/12/2008,[日期时间]

目前，我被要求查看此内容，每次我们希望从该表中进行选择时，我们都必须将值转换为指定的类型。我能够对此进行数据库重新设计，并且想知道优化它的最佳途径。（SQL 2000）。

您将如何在数据库中建模这些关系？

您有一个可以包含 PageElements 的 Page 实体。

PageElement 例如可以是文章或图片。文章表显然具有除图片之外的其他成员/列。一篇文章可以有ie。“Title”、“Lead”、“Body”列都是 nvarchar 类型，而 Picture 可能有“AltText”、“Path”、“Width”、“Height”之类的内容。我喜欢它是可扩展的，谁知道我在 3 个月内可能需要什么 PageElements？所以我想我需要一个 PageElementTypes 表。

对于关系，像这样的表呢：

带有 Id 的页面，以及其他的胡言乱语。（创建日期，可见，什么不）

Pages_PageElements与 PageId 和 PageElementId。

具有 Id 和PageElementTypeId的 PageElements 以及更多的 mumbojumbo（SortOrder、Visibility 等）。

具有 Id 和名称的PageElementTypes（例如“文章”、“图片”、“地址块”）

现在，我应该在每个 Articles、Pictures、AddressBlocks 表中创建一个 PageElementId 列来完成吗？这就是我有点卡住的地方，这是一个简单的 1:1 关系，所以这应该可以工作，但不知何故我可能会错过一些东西。

跟进：

下面推荐的具有单独属性的解决方案将迫使我将所有属性存储为同一类型，或者不是？如果一个 PageElement 的属性是 nvarchar(255) 并且有些是 nvarchar(1000)，如果有些是整数怎么办？

如果我采用 EAV 方式，我将不得不创建大量表来保存所有不同数据类型的属性值。

我在数据库中有一个表（基于 Postgres），它就像面向对象编程中的超类。它有一个“类型”列，用于确定表中应存在哪些附加列（子类属性）。但我不希望该表包含所有可能的列（所有可能类型的所有属性）。

所以我决定制作一个表，包含“key”和“value”列（即“filename”=“/file”或“some_value”=“5”），其中包含对象的任何可能属性，不包括在内在超类表中。并且还制作了一个相关表来包含可用的“关键”值。

但是这种架构存在一个问题——默认情况下，“值”列应该是字符串数据类型，才能包含任何内容。但我不认为转换为字符串和从字符串转换是一个好的决定。绕过此限制的最佳方法是什么？