SQL 服务器：设计问题 - 将记录存储为行与 BLOB - NVARCHAR(MAX)
SQL Server: Design question - stored records as rows vs as BLOB - NVARCHAR(MAX)
我正在创建一个时间表供我们的工程师分析。每天下载时间表，并在本地计算机上进行分析。
所以，现在，我陷入了将时间表存储为 table 行或 nvarchar(max) 的困境。
这是要求
- 每天都会生成时间表。每个时间表精确到 1 秒。因此，每个 计划 .
最多包含 86,400 条记录
- 一天内，根据设置，系统可以为每个工程师生成多达 100 个计划（我们有大约 10 个工程师）
- 时间表包含以下字段：
INT | INT | INT | INT | NVARCHAR(1024) | NVARCHAR(64) | BIT | BIT | DATETIME | DATETIME（总结：4x INTs，2x NVARCHARs、2x BITs 和 2x 日期时间)
- 时间表很少会更新，但可以更新。 updatable 字段是：2x BITs 和 1x DATETIME .
现在看看常见的情况：
In a day, it will generates about 1,296,000 records per day.
This is the calculation of common case scenario:
- 10 seconds accuracy per schedule = 8,640 rows
- 5 engineers run the scheduler each day
- Each engineer generates about 30 schedules
So total is: 8,640 * 5 * 30 = 1,296,000 records
如果我将每个计划存储为 逗号分隔 的 NVARCHAR(MAX)，那么记录数将减少到每天仅 150 条记录.
Here is the calculation:
- 10 seconds accuracy per schedule = 8,640 rows --> stored as NVARCHAR (becomes 1 record)
- 5 engineers run the scheduler each day
- Each engineer generates about 30 schedules
So total is: 5 * 30 = 150 records
现在，这是这些时间表的要求：
- 生成的日程表可以在网站上查看。
- 应用程序每天下载时间表进行分析。
- 分析完成后可以更新字段（2x BIT）。这些字段可以由应用程序更新（完成分析计划后），也可以由工程师在网站上更新（手动）。
- 所有生成的计划必须至少保存 3 个月以供审核。
你有什么建议？将计划存储为 table 行 或 NVARCHAR(MAX)
除了行计数之外，它们将数据存储在一列中有什么好处吗？如果没有，对我来说，你可以保存以规范化方式存储数据。
由于不同的需求，我使用了两种技术来存储数据。当然，将数据存储在 VARBINARY(MAX) 或 NVARCHAR(MAX) 中会导致许多困难：
- 无法按某些字段编制索引和搜索
- 为了执行更新，必须对数据进行规范化、修改，然后再次构建为 string/binary
- 为了执行报告，数据必须再次归一化
所以，鉴于以上原因，我会建议选择 table 格式。此外，如果您觉得以某种序列化方式导出数据更好，如果使用 SQL Server 2017 及更高版本，您始终可以实现这样的 SQL CLR string concatenation or use the built-in。
此外，最好使用 separators，如 CHAR(31) 和 CHAR(30) 用于列和行。然后使用 tab/new lines/commas/semi-colons 更清楚，因为输入数据不太可能包含此类数据并破坏您的数据。
我正在创建一个时间表供我们的工程师分析。每天下载时间表，并在本地计算机上进行分析。
所以，现在，我陷入了将时间表存储为 table 行或 nvarchar(max) 的困境。
这是要求
- 每天都会生成时间表。每个时间表精确到 1 秒。因此，每个 计划 . 最多包含 86,400 条记录
- 一天内，根据设置，系统可以为每个工程师生成多达 100 个计划（我们有大约 10 个工程师）
- 时间表包含以下字段：
INT | INT | INT | INT | NVARCHAR(1024) | NVARCHAR(64) | BIT | BIT | DATETIME | DATETIME（总结：4x INTs，2x NVARCHARs、2x BITs 和 2x 日期时间) - 时间表很少会更新，但可以更新。 updatable 字段是：2x BITs 和 1x DATETIME .
现在看看常见的情况：
In a day, it will generates about 1,296,000 records per day.
This is the calculation of common case scenario:
- 10 seconds accuracy per schedule = 8,640 rows
- 5 engineers run the scheduler each day
- Each engineer generates about 30 schedules
So total is: 8,640 * 5 * 30 = 1,296,000 records
如果我将每个计划存储为 逗号分隔 的 NVARCHAR(MAX)，那么记录数将减少到每天仅 150 条记录.
Here is the calculation:
- 10 seconds accuracy per schedule = 8,640 rows --> stored as NVARCHAR (becomes 1 record)
- 5 engineers run the scheduler each day
- Each engineer generates about 30 schedules
So total is: 5 * 30 = 150 records
现在，这是这些时间表的要求：
- 生成的日程表可以在网站上查看。
- 应用程序每天下载时间表进行分析。
- 分析完成后可以更新字段（2x BIT）。这些字段可以由应用程序更新（完成分析计划后），也可以由工程师在网站上更新（手动）。
- 所有生成的计划必须至少保存 3 个月以供审核。
你有什么建议？将计划存储为 table 行 或 NVARCHAR(MAX)
除了行计数之外，它们将数据存储在一列中有什么好处吗？如果没有，对我来说，你可以保存以规范化方式存储数据。
由于不同的需求，我使用了两种技术来存储数据。当然，将数据存储在 VARBINARY(MAX) 或 NVARCHAR(MAX) 中会导致许多困难：
- 无法按某些字段编制索引和搜索
- 为了执行更新，必须对数据进行规范化、修改，然后再次构建为 string/binary
- 为了执行报告，数据必须再次归一化
所以，鉴于以上原因，我会建议选择 table 格式。此外，如果您觉得以某种序列化方式导出数据更好，如果使用 SQL Server 2017 及更高版本，您始终可以实现这样的 SQL CLR string concatenation
此外，最好使用 separators，如 CHAR(31) 和 CHAR(30) 用于列和行。然后使用 tab/new lines/commas/semi-colons 更清楚，因为输入数据不太可能包含此类数据并破坏您的数据。