数据库表按实体组织，还是按数据级别垂直组织？答案

【问题标题】：DB table organization by entity, or vertically by level of data?数据库表按实体组织，还是按数据级别垂直组织？
【发布时间】：2012-09-06 08:04:00
【问题描述】：

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

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

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

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

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

非常感谢。

【问题讨论】：

如果我正确理解了您的现有结构，那么它提供的最大优势是添加/编辑/删除实体类型的灵活性。存储差异应该是最小的，因为两个结构都不应该复制不必要的数据。假设两种设计都采用了合理的索引，性能差异将在很大程度上取决于您希望对数据运行的查询——但我希望现有设计比每个实体包含一个表的非规范化形式要慢。
此外，我不会说现任结构缺乏“组织清晰”。如果您希望以某种方式查看您的数据，或在其上运行某些报告，请创建VIEW 或为该报告构建查询。仅仅因为数据以一种方式存储在数据库中并不意味着用户应该以这种方式与之交互。
您目前似乎患有某种 EAV。 SO上有很多关于这个的帖子，--这是一个起点stackoverflow.com/search?q=%5Bdatabase-design%5D+EAV
@eggyal，感谢您提供有用的反馈。我是该系统的新手，但您似乎提供了一个很好的答案（我们拥有的结构应该更灵活，更大并且可能不那么快，）您为什么不将其格式化为一个？关于“组织清晰”的评论，我可能应该添加“给我”，因为对于比我更好地阅读 php 和 sql 的人来说，组织无疑是非常清楚的。我的意思是，对于一个典型的组织，我可以使用 phpMyadmin 打开一个表并直接查看数据，但我现在不能这样做。
@Damir，太好了，我以前从未听说过 EAV。从那以后我了解到它们针对灵活性进行了优化，特别是在输入数据而不是检索时（这可能对我们有好处）并且通常用于稀疏数据的情况（这没有描述我们）但似乎有很多谨慎围绕着他们。我们将进一步探索。

标签： mysql database-design entity-relationship

【解决方案1】：

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

一种非常非结构化的方法，每个事实或数据点都被转储到一个大表中，并具有理解它所必需的特征。这使得添加更多数据变得容易，但它可能会很慢和/或很难将其取出。 EAV 已针对添加数据和组织灵活性进行了优化，而且支付方式是访问速度较慢且编写查询更加困难等。
一种“又长又瘦”的格式，行多，列少。
由于数据是“自编码”的，具有自己的特征，因此通常在您知道可能有很多特征或数据点但其中大部分为空（“稀疏数据")。表格方法会有很多空单元格，但 EAV 并没有真正的单元格，只有数据点。

在我们的特殊情况下，我们没有稀疏数据。但我们确实有这样一种情况，即添加数据的灵活性可能很重要。另一方面，虽然我认为访问速度对我们来说并不那么重要，因为这不会是一个访问量很大的站点，但我会担心创建查询和表单的难易程度。最重要的是，我认为这种结构对于我们 BD 菜鸟来说很难理解和控制，所以我倾向于传统模型——牺牲灵活性，也许为了清晰而容易添加新数据。此外，人们似乎同意只要数据关系真正需要大量表就可以了。所以，决定了。

【讨论】：