sql - 我应该使用平面表还是规范化数据库？

Question

我有一个我目前正在开发的 Web 应用程序，它使用 MySQL 数据库作为后端，在我继续之前，我需要知道什么对我的情况更好。

简单地说，在这个应用程序中，用户将能够使用任何数字字段（他们决定）构建自己的表单，现在我将它们全部存储在由外键链接的几个表中。我的一个朋友建议，为了让事情“简单/快速”，我应该将每个用户的表单转换为一个平面表，以便从他们那里查询数据保持快速（以防大幅增长）。

我应该使用外键（索引等）将所有内容汇集到关系表中来保持数据库规范化，还是应该为用户创建的每个新表单构建平面表？

显然，创建平面表的一些好处是数据分离（安全）和查询速度会降低。但是说真的，我会从中获得多少收益？我真的不想要 10000 个表并且一直在删除、更改和添加，但如果它比我会做的更好......我只需要一些输入。

谢谢

score 22 · Accepted Answer

经验法则。从规范化到非规范化比反过来更容易。

从合理级别的数据库规范化开始（合理的意思是可读、可维护和高效，但不会过早优化），然后如果您在成长过程中遇到性能问题，您可以选择研究非规范化可以提高性能的方法。

score 6 · Accepted Answer

保持数据标准化。如果索引得当，很长一段时间内都不会遇到性能问题。

关于安全性：扁平化方法需要您编写大量的创建/删除表、更改表等语句，即更多的代码和更多的故障点。

拥有平面文件的唯一原因是您的用户可以直接连接到数据库（您仍然可以寻求行级安全性）。但在这种情况下，您实际上是在重新实现 phpmyadmin 的变体

score 3 · Accepted Answer

...在此应用程序中，用户将能够使用任何数字字段构建自己的表单...

哎呀！那么，当用户本质上为您做出数据库决策时，您怎么可能进行任何形式的规范化。

我认为您要么需要逐步管理它，要么让您的怪胎旗帜飘扬，并继续购买硬件以跟上当用户真正开始使用它时您将要获得的震撼……例如，看看当用户开始了解如何在 SharePoint 中创建新的表单和视图时会发生什么...CRIKY！谈论范围蔓延！

score 2 · Accepted Answer

在运行时更改架构很少是一个好主意。您要考虑的是EAV（实体-属性-值）模型。

维基百科有一些关于利弊的非常好的信息，以及实施细节。应尽可能避免 EAV，但对于像您这样的情况，每个表单的列数未知，EAV 值得考虑。

score 1 · Accepted Answer

保持数据标准化。如果您有适当的索引，系统将保持快速。

如果你真的想快点，那么将模式切换到 bigDB /couchDB 等键值数据库之一。这完全是非规范化的并且非常非常快。

score 1 · Accepted Answer

我处理这个问题的方法是使用一个标准化的、可扩展的“属性”表，如下所示：

Table: FormProperty
 id: pk
 form_id: fk(Form)
 key: varchar(128)
 value: varchar(2048)

上面只是一个例子，但我在很多情况下都使用过这种模式，而且效果很好。唯一真正的“陷阱”是您需要将值序列化为字符串/varchar，然后将其反序列化为所需的任何内容，因此客户端需要承担一些额外的责任。

score 0 · Accepted Answer

规范化 == 快速搜索，更容易维护索引，更慢的插入事务（在多行上）

非规范化 == 快速插入，通常在有大量插入时使用（收集和记录时序数据的数据仓库）

7 回答 7