mysql - 什么更有效，一个表有 100 列和更少的行或 5 列和多 30 倍的行

Question

编辑 1:

因为很少有人指出我的问题不是很清楚，所以我想我现在会重写它并使其更清楚。

所以基本上，我正在制作一个应用程序，它允许用户使用自己的一组输入字段创建自己的表单，其中包含名称、类型等数据。创建表单并发布表单后，只要有在表单中输入，数据被保存到当然的数据库中。因为表单本身是动态的。我需要一种方法来保存这些数据。

我的第一选择是将其 JSON 化并保存。但是因为我无法对它们执行任何 SQL 查询，所以如果我以 JSON 格式保存，我将取消此选项。

然后简单的方法是存储在一个表中，如 (id, rowid, columnname, value) 并且我保持所有行数据的 rowid 相同。但是这样一来，如果一个表单包含 30 个字段，那么在 100 个条目之后我的数据库将有 3000 行。所以从长远来看，它会变得很大，我认为当表中有数百万行时查询会变慢。

然后我有了这样一个表的想法，例如 (id, rowid, column1, column2...column100)。我会将表单中的所有输入保存到单行中。通过这种方式，它确实每次提交只添加 1 行，而且它也更容易查询。我将存储实际的列名并将它们从那里映射到正确的列(数字)。这是我的想法。 column100，因为 100 是用户可以在其表单中添加的最大输入数。

所以我的问题是，我的想法好不好，还是应该坚持经典表。

Answer 1

如果我理解了您的问题，您需要设计一个数据库结构来存储您事先不知道其架构的数据。

这很难 - 据我所知，在关系数据库中没有“高效”的解决方案。

选项 1 是改为查看非关系 (NoSQL) 解决方案。

我不会详细说明优点和缺点，因为它们在很大程度上取决于您选择的 NoSQL 选项。值得注意的是，许多关系引擎(包括 MySQL)允许您存储和查询结构化数据格式，如 JSON .我自己没有在 MySQL 中使用过此功能，但 SQL Server 中的类似功能表现非常好。

在关系数据库中，常见的解决方案是“实体/属性/值”( EAV ) 模式。这有点像您的选项 2。

EAV 设计理论上可以存储无限数量的列和无限数量的行 - 但常见查询很快变得不可能。在您的示例数据中，查找名称以 K 开头且幂至少为 22 的所有记录变成了一个非常复杂的 SQL 查询。这也意味着应用程序需要执行唯一性规则、强制/可选数据属性以及从一种格式到另一种格式的数据转换。

从性能的角度来看，这并不能真正扩展到复杂的查询。这是因为“where”中的每个子句都需要自连接，索引不会对非文本字符串的搜索产生很大影响(搜索数字“大于 20”与搜索文本“不同”大于 20").

实际上，选项 3 是使模式逻辑适合有限数量的列(您的选项 1)。

这意味着你对列数有限制，你仍然需要在应用程序中管理强制/可选、唯一性等。但是，查询数据应该更容易 - 查找名称以 K 开头且幂至少为 22 的帐户是一个相当简单的练习。

您确实有很多未使用的列，但这并不会真正影响性能 - 磁盘空间非常便宜，所有浪费的空间可能比您在智能手机中携带的空间还少。