Question

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

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

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

显然，创建平面表的一些好处是数据分离（安全性），并且会降低查询速度。但是，我会从中获得多少收益呢？我真的不想要10000个表，而且要丢弃，改变和添加所有的时间，但是如果它会比我更好......我只需要一些输入。

谢谢

Answer 1

经验法则。从规范化到非规范化比从另一种方式转向更容易。

从合理水平的数据库规范化开始（合理的意思是可读，可维护，高效但不过早优化），然后如果你在增长时遇到性能问题，你可以选择反规范化的方法。提高绩效。

Answer 2

保持数据规范化。如果索引正确，很长一段时间内都不会遇到性能问题。

关于安全性：平面方法将要求你编写大量的创建/删除表，alter table等语句，即更多的代码和更多的失败点。

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

Answer 3

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

糟糕！那么当用户为您做出数据库决策时，你怎么能可能进行任何类型的规范化。

我认为你要么需要一步一步地管理它，要么让你的怪异旗帜飞起来，只是保持购买硬件以跟上当用户真正开始进入它时你将会得到的颠簸....举个例子，看看当用户开始了解如何在SharePoint中创建新表单和视图时会发生什么...... CRIKY !!谈论范围蔓延!!

Answer 4

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

维基百科有some very good info的优缺点以及实施细节。尽可能避免使用EAV，但对于像你这样的情况，每种形式的列数都是未知的，EAV会考虑这样做。

Answer 5

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

如果你真的想要快速，那么将模式切换到一个关键值数据库，如bigDB / couchDB等。这完全非规范化，非常快。

Answer 6

我要处理的方法是使用规范化，可扩展的“Property”表，如下所示：

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

以上只是一个例子，但我在很多情况下都使用过这种模式，而且它的效果非常好。唯一真正的“问题”是你需要将值序列化为字符串/ varchar，然后将其反序列化为它需要的任何东西，因此在客户端上有一点额外的责任。

Answer 7

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

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