1

我希望标题清楚，请进一步阅读，我将解释我的意思。

我们与我们的数据库设计师在高级结构方面存在分歧。我们正在设计一个 MySQL 数据库，我们有大量数据将成为其中的一部分。从概念上讲，数据是复杂的——有几十种不同类型的实体（代表各种现实世界的实体，您可以将它们视为产品开发人员、工厂、产品、检验、认证等），每种实体都有相关的特征和与彼此的关系。

我不是一个经验丰富的数据库设计师，但我所知道的一切都告诉我首先将这些实体中的每一个视为一个表（具有代表特征的相关字段和填充它们的数据），并在给定基础关系的情况下进行适当连接。我见过的每个数据库设计示例都是这样做的。

然而，数据目前是完全不同的形式。有四个表，每个表代表一个数据级别。顶级表列出了 39 种实体类型，并有一个长的字母数字字符串将其与其他三个表相关联，这些表表示所有实体（在一个表中）、实体特征（在一个表中）和数据库中所有特征的值（在一个包含数千万条记录的表中。）这很有效 - 我们在 php 中有一个基本视图，可让您在各个级别之间导航并查看数据等 - 但至少可以说它是不直观的。采用这种方式的原因是它使 DB 的大小更小，缩短了查询时间，并使扩展更容易。但我不清楚数据库的大小是否意味着我们应该优化它，比如组织的清晰度。

所以问题是：有没有理由以这种方式构建数据库，它是什么？我发现很难处理基础数据——例如，你不能以传统的行和列格式遍历表格——而且它隐藏了连接。但是基于实体的表的更“传统”结构会产生更多的表，规范化后肯定会超过 50 个。哪种方法看起来更好？

非常感谢。

4

1 回答 1

0

好的，我将继续根据我得到的评论和他们引导我进行的更多研究来回答我自己的问题。直接的答案是肯定的，可能有理由用很少的表来构建数据库，并且其中一个表中包含所有数据，它是一个实体-属性-值数据库 (EAV)。它们的特点是：

  • 一种非常非结构化的方法，每个事实或数据点都被转储到一个大表中，并具有理解它所必需的特征。这使得添加更多数据变得容易，但它可能会很慢和/或很难将其取出。EAV 已针对添加数据和组织灵活性进行了优化，其代价是访问速度较慢且编写查询更加困难等。

  • 一种“又长又瘦”的格式，很多行，很少的列。

  • 因为数据是“自编码”的，具有自己的特征，所以它通常用于当你知道会有很多可能的特征或数据点但其中大部分都是空的（“稀疏数据”）的情况下。会有很多空单元格，但 EAV 并没有真正的单元格，只有数据点。

In our particular case, we don't have sparse data. But we do have a situation where flexibility in adding data could be important. On the other hand, while I don't think that speed of access will be that important for us because this won't be a heavy-access site, I would worry about the ease of creating queries and forms. And most importantly I think this structure would be hard for us BD noobs to understand and control, so I am leaning towards the traditional model - sacrificing flexibility and maybe ease of adding new data in favor of clarity. Also, people seem to agree that large numbers of tables are OK as long as they are really called for by the data relationships. So, decision made.

于 2012-09-10T04:54:41.093 回答