我尝试过规范化的表格设计。问题（可能）是我们生成了大量数据，因此产生了很多行。目前，该数据库的规模每天增加0.25 GB。
主要表格是样本盒子。从样本到盒子之间存在一对多的关系。 样本表：
ID | Timestamp | CamId
方框表：
ID | SampleID | Volume | ...
我们每5秒分析19个样本，平均每个样本有7个盒子。那个19 * 7 * 12 =每分钟1596个盒子，每天在Boxes表中有1596 * 60 * 24 = 2,298,240个行。
此设置可能会持续数月。此时Boxes表有大约2500万行。
Quistion是;我应该担心数据库大小，表格大小和表格设计有这么多数据吗？
或者我应该有像
这样的表格ID | SampleID | CamId | Volume1 | Volume2 | ... | Volume9 | ...
答案 0 :(得分：1)
根据数据的有效性，您可以实施数据清除。 我的意思是：你真的需要几天前，几个月前，几年前的数据吗？如果您有数据使用时间限制，请清除它们，并且数据表应在一段时间后停止增长（或可能）。
通过这种方式，你不需要为了大小而关心这两种架构。
否则答案是肯定的，你应该关心。许多表格中的单独概念可以为您提供良好的性能调整，但在很长一段时间后访问时间可能不够。考虑使用NoSQL解决方案或同样的方法来存储大量的行。
答案 1 :(得分：1)
有一条简单的规则：每当您认为必须为列名添加数字时，您可能需要一个相关的表。
数据量大致相同，此处没有胜利。
我会尝试对表格进行分区。 AFAIK此功能已绑定到企业版，但是 - 根据this document - 使用SQL Server 2016 SP1表和索引分区即使到了Express！
主要问题是：您打算如何处理这些数据？
如果您必须通过所有运行分析脚本，那么购买更好的硬件将没有更好的提示。
如果您的需求参考了过去3周的数据，那么分区就可以了。
如果您尚未使用此功能（由于您的服务器版本），您可以创建存档表并在常规作业中将旧数据移动到此表中。 UNION ALL视图仍然可以抓住整个视频。使用SCHEMA BINDING，您甚至可以获得索引视图的优势。
在这种情况下，将工作数据保存在最快的驱动器中并将存档表放在其他地方的大型存储上的单独文件中是很聪明的。
答案 2 :(得分：0)
问题是，我是否应该担心数据库大小，表格大小和表格设计有这么多数据？
我的回答是YES:
1. A huge amount of data(daily) should affect your storage in hardware part.
2. Table normalized is a must mostly if you are storing bytes or images.