我应该在 SQL 中使用嵌套数据结构吗？答案

【问题标题】：Should I use nested data structures in SQL?我应该在 SQL 中使用嵌套数据结构吗？
【发布时间】：2022-01-17 00:27:17
【问题描述】：

我在 SQL Server 中有一个相当大的数据库。为了说明我的用例，假设我有一个手机游戏，我想报告用户活动。

首先我有一个看起来像这样的表：

userId	date	# Sessions	Total Session Duration
1	2021-01-01	3	55
1	2021-01-02	9	22
2	2021-01-01	6	43

我正在尝试将每个会话的信息“添加”到此数据中。我正在考虑的选项是：

这在 SQL Server 中可行吗？（我的经验来自 GCP 的 BigQuery）

【问题讨论】：

任何一种方法都是可行的，具体取决于您需要如何处理这些信息。如果您要经常查询数据，那么我会敦促您将数据正确规范化到相关表中。如果你不这样做，你将不断地解析你的 JSON 值，这并不理想。但如果是更多的历史数据，那么将其存储为 JSON 可能是一个非常合理的解决方案。这里最大的问题是没有足够的信息来提供太多帮助。任何建议都将基于意见。
是的。事实上，我正在尝试为一些字段构建类似“迷你图”的东西 - 我不确定嵌套 JSON 是否比获取数据的多个查询更好。 IE。是否值得尽量减少对数据库的查询次数？
最小化查询将以标准化、查询复杂性和最重要的性能为代价。正确规范化的数据库性能更高。 JSON 和 XML 等是为值的结构完全未定义而设计的，并且您只想存储一个 blob 供应用程序检索（想想文档、PDF、XHTML、来自非常不同来源的数据）

【解决方案1】：

您的问题归结为是使用嵌套数据更好还是找出一个表系统更好，其中每个表的每一列都有一个简单的域（文本字符串、数字、日期等）。

事实证明，这个问题是 Ed Codd 在 50 年前提出第一个基于关系模型的数据库系统时正在思考的问题。他认为将关系数据库限制为范式是值得的，后来更名为第一范式。他自己满意地证明了这种限制不会降低关系模型的表达能力。并且可以更轻松地构建第一个关系数据库管理器。

从那时起，几乎每个关系或 SQL 数据库都符合第一范式，尽管有一些方法可以通过将各种形式的数据结构中的一种存储在表的一列中来绕过限制。 JSON 就是一个例子。

您将获得使用 JSON 获得的灵活性，但您将无法使用 SELECT 语句的各种子句（如 INNER JOIN 或 WHERE 等子句）指定要检索的数据。这种损失可能会成为交易杀手。

如果是我，我会采用添加表的方法，并将会话数据分析到具有简单列的多个表之一。但您可能会发现 JSON 解码器同样强大，而且花时间进行全表扫描是值得的。

【讨论】：