巨大的数据库表设计问题

Question

在我的数据库设计中，我遇到了一个问题。我的应用程序包含特定媒体类型的工作流程，有以下6个阶段：

1. 资源
2. 摄取
3. 评分
4. VideoRepair
5. 清单
6. 备份

由于在所有阶段中，向表添加（或更新）的数据类型是相同的，但只有它们的名称会更改，例如在摄取中我们有以下列

CaptureSup_Name, Assign_DateByCaptureSup, AssignedCaptureOp_Name,
LastCapture_Date, LastCaptureOp_Name, LastCapture_Date,

并且在评论中我们有完全相同的列，但只有Ingest替换为Review，并且对于表的其他列（或多或少有一列或多列）几乎相同，并且为了在选择查询上具有更好的性能所以我决定不为每个阶段（传统规范化）分配一个表格，相反我将它们全部包装在一个统一的表格中

现在我的桌子有30列，列数30，这让我感到害怕，因为我从未设计过如此大的桌子。考虑到我的数据库应该支持大量数据（每天添加大约1500条记录）并且速度至关重要，以下哪种情况最适合我的情况？

1. 遵循传统的规范化方法，将我的大表分成6或7个表，每个表都有大约5或6列o我必须编写（n-1）个连接以检索循环的完整数据

2. 保持我当前的设计（一个表有30列）并找到减少日志大小的解决方案，因为在这种情况下，日志会更大（因为更新）

我很欣赏你仁慈的答案。

Answer 1

评论太长了。

30个字段不是宽表。 SQL Server支持每个表超过1,000个字段。

每天1500条记录不是大量的插入。那每年只有大约50万行。 SQL Server可以处理数十亿行。

如果您遇到日志问题，那么您有几个选项，例如：

• 切换到简单恢复模式;
• 定期备份数据库并截断日志;和，
• 使用数据库检查点。

如果在关系模型方面有意义，你应该将表分成其他表 - 这很可能，因为表中的30列通常是其他实体的组合。但是，您的数据结构很容易在数据库容易支持的范围内。并且，它可以增长得更多，更大而没有任何问题（假设你的列都不是真的很棒）。