在 MySQL 中存储 JSON 时多少算太多答案

【问题标题】：How much is too much when storing JSON in MySQL在 MySQL 中存储 JSON 时多少算太多
【发布时间】：2022-10-16 11:21:25
【问题描述】：

我想知道我为我的 uni 组织网站所做的当前数据库设计。一般而言，本网站用于显示信息和事件。每个部门的活动都不同。它做了一些正常的事情，比如显示事件、为管理员创建事件、为用户注册事件等。问题是每个部门可能有不同的表单来注册新参与者，比如部门 A 有 5 个表单输入，但部门 B 有 8 个表单输入.然而，每个事件可能有不同的形式，具有多种类型，如文本、单选或复选框。

为了解决我之前提到的问题，我设计了具有events、departements、event_forms、form_types、event_form_options 的数据库（当管理员决定选择该类型的表单时，用于复选框或收音机），@ 987654326@，以及其他一些不在此问题范围内的表格。我的想法是，管理员可以创建他们想要的任意数量的表单输入，并且每个表单输入等于event_forms 表的一行，该表引用了某些event 和event_id。但是这种方法可能出现的“问题”在于event_form_responses 表。在该表中，用户将对特定事件的每个表单输入做出响应。比如说，event A 有 10 个表单输入，然后有 60 人决定注册该活动，这意味着 event_form_response 仅针对该活动就有 600 行响应！然后它需要显示在管理仪表板中。

我的问题：

这会影响查询和网站性能吗？我认为会的。如果我更改 event_form 和 event_form_responses 以将其存储为 JSON 会怎样？在这一点上是否更有优势？这样每个event_form 都可以轻松地拥有不同签名和不同数量的表单输入。对于event_form_responses 将有1 * U 而不是Q * U，U 是在所述事件中注册的用户总数，Q 是表单输入的数量。先感谢您

【问题讨论】：

我的基本问题是，数据是否会改变，你必须问自己我是否适合 json 来处理更新查询和复杂的 json 查询等。
如果你想走 JSON 的路线，你可以考虑 MongoDB
@nbk 对于表单输入，可以更改。至于event_form_responses 是静态的。哪个更好，两个表 event_form 的 json 或中间部分，每个表单输入使用每一行，event_form_response 的 json，你怎么看？
@newtocoding我尽量避免使用json，我可以随意操作它们，但这总是很麻烦，所以尽量将数据保存为标准化，siz 通常是不相关的，只有当你可以使用工具来操作
@nbk 如果我告诉你 json 永远不会像使用 where 子句或其他东西搜索一样查询。当然，它可以更改，但话又说回来，它可以用 id 检索

标签： mysql laravel database mysql-json

【解决方案1】：

我不会担心每个事件有 600 行。假设您已经很好地设计了索引来支持您的查询，那么 MySQL 可以处理每个表的数亿行。当您拥有超过 10 亿 (1e9) 行时，表通常开始变得难以扩展。

我已经回答了a lot of questions about MySQL and JSON on Stack Overflow。我的结论是，虽然 JSON 使存储具有可变或复杂结构的数据变得容易，但它是有代价的。

针对 JSON 数据的查询比针对普通行和列的传统 SQL 查询更复杂。学习搜索或排序存储在 JSON 中的数据更加困难。并非不可能——但这是一种完全不同类型的查询。如果您还没有这方面的经验，您将经历一个陡峭的学习曲线。

你说你关心性能，我发现优化搜索或排序 JSON 的查询比使用普通表的查询更难。

此外，这在很大程度上取决于您如何构建 JSON。 JSON 是非常自由的形式，您可以创建数组和键/值对象，并且可以嵌套进一步的结构。但在某些情况下，我看到人们创建无法使用 MySQL 的 JSON 函数查询的 JSON 结构。您需要对可用的 JSON 函数类型进行大量研究，并进行大量动手实验以了解它们的优缺点。

我还发现，与在普通行和列中存储等效数据相比，以 JSON 格式存储数据通常需要 2-3 倍的空间。原因是数字存储为字符串，对象键出现在每一行而不是只出现在表头中，引号、逗号和括号需要额外的字符。

您可能会喜欢我的演示文稿How to Use JSON in MySQL Wrong。

【讨论】：

我认为json不会被查询，比如用where子句搜索什么的，它只需要显示。最多可以更改event_form，但同样可以根据id查询数据。至于event_form_responses 不能更改。或者，也许，采取中间部分？就像，每个表单输入使用每一行，event_form_response 使用 json，你怎么看？
在我的演示文稿中，我说如果您必须使用 JSON，请遵循以下粗略指南：在您的选择列表中引用 JSON 列，但不要在 WHERE 子句（或任何其他子句）中引用。如果您的查询不使用 JSON 文档中的字段进行搜索或排序，那么您的状态可能会更好。不过，在某些情况下，您希望从 JSON 中提取某个字段。虽然从技术上讲，这是在选择列表的表达式中完成的，但存在您选择了难以从中提取值的 JSON 文档结构的风险。我鼓励您尝试并进行实验。
你的介绍真的很丰富，我喜欢。但是你能帮我解决这个问题吗？也许我们可以缩小这个问题也许我可以将每个表单输入存储为一行，因为我认为根据你的演示将它发送到网站会更快，并且它会被多次检索，因为它会显示在用户页面中。至于event_form_response，它只会显示在管理页面中。 json 仅用于用户的响应，将具有问题的标题和响应。哪个更好，之前只用600，还是用json减少总行？ (1/2)
因为我对600或更多的关注在网站上。你认为循环 600 次或更多来显示数据可以吗？这就是为什么我问这个问题，如果我用 json 格式减少行怎么办。虽然，它只是用于管理员但另一方面，我认为它是一样的，不是吗？我仍然需要循环 json 数据中的每个响应。也许我坚持我目前的设计？我不太确定（2/2）
我鼓励您尝试并进行实验。做一些动手工作比听我说的，你会学到更多。

【解决方案2】：

在阅读了@Bill Karwin 幻灯片演示、我自己的实验和一些兼职工作的经验之后，我得出结论，我将对这两个表都使用 json，原因如下：

对于even_forms 表，我意识到用户需要更新数据。因此，制作规范化版本将是困难/复杂的，因为我们不知道列用户可能会更改的位置，或者可能同时，用户希望以随机顺序同时添加或删除列。所以json更易于管理和更容易。
对于event_form_responses，我的前辈说我们需要限制从数据库中获取数据以保持网站的性能。通常它会在50左右。如果我要使其标准化，获取 10 个用户表单响应等于获取 100 个数据（如果事件表单有 10 个问题）。所以一次显示 5 个事件表单响应对用户体验来说并不是很好，是吗？但是，即使该网站的用户一次不会达到 10K 或其他什么（我认为最多 300 - 1000），我只是将其视为最佳实践

【讨论】：