Mysql 数据库设计：名称-值对-好还是坏？_Mysql_Database_Database Design

Mysql 数据库设计：名称-值对-好还是坏？

mysql database database-design

Mysql 数据库设计：名称-值对-好还是坏？,mysql,database,database-design,Mysql,Database,Database Design,假设我有一个在线商店，其中每个产品都有一个单独的类别（有数百个类别可供选择）（例如“书籍”、“便携式DVD播放器”等）。如果我需要为每个类别提供描述性字段（例如，“作者”将是“书籍”类别的字段），那么在数据库中表示这一点的最佳方式是什么选项1（名称-值对）：这意味着我可以依靠一个表来进行任何分类。我担心与其他书籍并排显示这些数据所需的数据透视可能是一个潜在的问题备选案文2（个别表格）：这意味着我需要每个类别的表注意：我并不认为这很重要，但类别将来自类别的层次结构（例如电子->DVD播放

假设我有一个在线商店，其中每个产品都有一个单独的类别（有数百个类别可供选择）（例如“书籍”、“便携式DVD播放器”等）。如果我需要为每个类别提供描述性字段（例如，“作者”将是“书籍”类别的字段），那么在数据库中表示这一点的最佳方式是什么

选项1（名称-值对）：

这意味着我可以依靠一个表来进行任何分类。我担心与其他书籍并排显示这些数据所需的数据透视可能是一个潜在的问题

备选案文2（个别表格）：

这意味着我需要每个类别的表

注意：我并不认为这很重要，但类别将来自类别的层次结构（例如电子->DVD播放机->便携式DVD播放机）

我的$0.02-每个类别一张表。如果事情真的不同，那就接受它，并相应地摆好桌子

当然，如果某些实体具有公共数据，则可以对其进行抽象/规范化，但我认为，您使用的名称/值对选项可能会导致一些严重的可读性/查询性能问题。

您确定要仅限于一个类别吗。我的意思是，你能想到任何情况下，你的产品可以属于多个类别

好吧，不管怎样，这里有一个可能对您有用的解决方案：

更新（添加了几层）

您有一个名为“director”的类型：

还有一些价值：

detail_value:
  detail_value_id: 200
  value: "James Cameron"

类型和值的映射：

detail_value_type:
  detail_value_type_id: 300
  detail_value_id: 200
  detail_type_id: 100

哪些详细信息属于产品：

product_detail_value_type:
  product_detail_value_type: 400
  product_id: 500
  detail_value_type_id: 300

然后我们有以下几类：

category:
  category_id: 600
  name: "movie"

和类别产品映射：

category_product:
  category_product_id: 700
  product_id: 500
  category_id: 600

最后是产品本身：

product:
  product_id: 500
  name: "Aliens"

我建议你把你的设计建立在互联网标签的基础上

让我解释一下：

在主对象表中还需要4个表

第一个：名称标签表，这是一个基本的表id |名称，它将存储对象的属性：“author”、“size”、“weight”；任何能描述物体的东西

tag_table
id    varchar(36)
tag   varchar(36)

第二个：此表将使值与存储在tag_表值中的标记名相匹配。它的设计是一样的

value_table
id    varchar(36)
value varchar(36)

第三个：将确定哪个值是哪个标记

tag_value
id_pair  varchar(36)
id_tag   varchar(36)
id_value varchar(36)

第四个：将对象与其数据连接起来，以对其进行carecrtize

object_tag_value
id_object  varchar(36)
id_pair    varchar(36)

最后是对象表

实施等级制度：

对于一对多或多对多层次结构，实现一个与两个对象相关的额外表：

object_relation
id_parent varchar(36)
id_son    varchar(36)

对于多对一（例如带有manager\u id的Employee表），只需添加id\u父对象作为对象的成员

有了这个模式，您将具有高度的可伸缩性，一个对象现在可以具有无限的特性，您不再受到限制。另外，由于标记名是唯一的，所以可以避免数据冗余

希望我说得够清楚，这对您有所帮助，

现实世界的注意事项-在我的工作中，我们有几种形式非常相似，但具有独特的属性-我们对每种形式都使用特定的表，一个用于一些常见元素（名称、地址等）的表，还有一些视图，当我们需要将这些对象作为一个整体来查看时，它们可以帮助我们聚合它们。也搜索“泛化-专业化-关系建模”。同意。名称-值对系统很难返回一个简单的数据表，每个类别（BookID、Author、Title等）都有一个列。您建议为每个类别创建一个表。如果您需要添加一个新类别，您是否需要为其创建一个新表？在生产中，我宁愿在现有表中添加一行，也不愿创建一个新表。在对象关系映射框架中，事情变得很棘手，比如在Rails中。具有讽刺意味的是，我们现在正在prod（新的医院表单）中这样做。添加一个新实体通常包括滚动新的UI组件、构建新的ORM映射等。总之，插入新表、新UI并连接好好东西只是我们用户故事的一部分：）@hade，现在你让我有点担心了。一个产品真的可以分为两类吗？我一直在研究亚马逊；不知道我是否见过这样的案例。我错了吗？@hade，这种设计使我有可能拥有不止一部“詹姆斯·卡梅隆”。这是标准化的吗？@StackOverflowNewbie：假设你有分类电影。你可以有不同格式的电影：VHS、DVD、蓝光。您想如何对它们进行分类？它们都是电影，但也可以根据媒体类型对它们进行分类。假设您要搜索蓝光格式的电影。你们可以通过搜索电影类和蓝光类的产品轻松做到这一点。是的，在这个设计中，你们可以有不止一个“詹姆斯·卡梅隆”。这是一个非常简单的例子。实际上，这部电影可以有几个导演，比如科恩兄弟。实际上，您需要单独的人员表以及详细信息和人员表之间的多对多关系。在你的例子中，也许“电影”是一个类别，“蓝光”是一个细节（就像其他细节：导演、流派等）。你觉得呢？等级制度呢？您的解决方案中没有层次结构的概念，对吗？层次结构有两个概念：1对多和多对多。如果需要一对多，在对象表中添加parentId非常简单。如果是多对多添加一个表层次结构，其中包含两个varchar（36）字段，这两个字段将是另一个对象之间的关系，您可以通过这种方式拥有无限的层次结构。如果我只需要一个1对多层次结构，我还应该使用您提出的解决方案吗？我修改了我的原始帖子，并写了一些关于层次结构的内容，是的，它适用于您的解决方案。

value_table
id    varchar(36)
value varchar(36)

tag_value
id_pair  varchar(36)
id_tag   varchar(36)
id_value varchar(36)

object_tag_value
id_object  varchar(36)
id_pair    varchar(36)

object_relation
id_parent varchar(36)
id_son    varchar(36)