Mysql DB表是按实体组织，还是按数据级别纵向组织？

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

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

我不是一个经验丰富的数据库设计师，但我所知道的一切都告诉我，首先要将这些实体中的每一个实体看作一个表（带有表示特征和填充它们的数据的关联字段），并根据基础关系进行适当的连接。我看到的每一个DB设计示例都是这样的

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

所以问题是：有没有这样构造DB的理由，它是什么？我发现很难获得底层数据的句柄—例如，您不能以传统的行和列格式运行表—而且它隐藏了连接。但是一个更“传统”的结构，基于实体的表，会产生更多的表，在规范化之后肯定会超过50个。哪种方法似乎更好

---

非常感谢。

好的，我将根据我得到的评论和他们引导我进行的更多研究，继续回答我自己的问题。直接的答案是肯定的，可能有理由用很少的表来构造一个数据库，并且所有的数据都在其中一个表中，这是一个实体属性值数据库（Entity Attribute Value database，EAV）。其特点是：

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

• 一种“长而窄”的格式，行很多，列很少

• 由于数据是具有自身特征的“自编码”数据，因此通常在您知道可能有很多特征或数据点，但其中大多数是空的（“稀疏数据”）的情况下使用。表格方法会有很多空单元格，但EAV实际上没有单元格，只有数据点

---

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

如果我正确理解了您现有的结构，那么它提供的最大优势是在添加/编辑/删除实体类型方面的灵活性。存储差异应该是最小的，因为两种结构都不应该复制不必要的数据。假设在两种设计中都有合理的索引，那么性能差异将非常大取决于您希望针对数据运行的查询——但我认为现有的设计要比每个实体包含一个表的非规范化表单慢。此外，我不会说现有的结构缺乏“组织的清晰性”"。如果您希望以某种方式查看数据，或在数据上运行某种报表，请创建一个

视图
或为该报表生成一个查询。仅仅因为数据以某种方式存储在数据库中，并不意味着这是用户应与之交互的结构。您当前似乎有某种EAV。有许多帖子基于此，——这里是一个起点@eggyal，谢谢你的有用反馈。我是这个系统的新手，但你似乎提供了一个很好的答案（我们的结构应该更灵活，更大，也许更快），你为什么不把它格式化为一个呢？关于“组织清晰性”的评论，我可能应该加上“给我”因为对于比我更了解php和sql的人来说，这个组织无疑是非常清楚的。我的意思是，对于一个典型的组织，我可以用phpMyadmin打开一个表，直接查看数据，但我现在不能这样做。@Damir，太好了，我以前从未听说过EAV。我后来了解到它们是针对flexibil优化的不确定性，尤其是在输入数据而不是检索数据时（这可能对我们有好处），通常用于稀疏数据的情况（不描述我们），但似乎有很多谨慎的地方。我们将进一步探讨。