使用的行数/列数与它在（MS）SQL数据库中的影响之间是否存在相关性？
多一点背景：
我们必须存储来自测量设备的大量数据。这些设备每天大约100次向我们发送数据字符串。这些字符串包含+ - 300个字段。假设我们有100台设备在运行，这意味着我们每天都会收到10000条记录。在我们的后端，我们拆分这些数据字符串，并将它们放入数据库中。当这些数据字符串被修复时，这意味着我们每天将大约10000个新行添加到数据库中。没什么大不了的。
无论如何，这些数据字符串的内容可能会在一段时间内发生变化。我们正在考虑两种选择：
从轻松的角度来看，我们想选择第一种方法。无论如何，这意味着我们每天要添加100 * 100 * 300 = 3000000行。数据必须存储1年零一个月（395天），因此我们的行数约为12亿行。没有计算出预期的增长。
从表现的角度来看，使用“纵向”是否更为智能？或者横向的＆＃39;接近？
选择＆＃39;垂直＆＃39;解决方案，我们如何明智地使用PK＆FK / FK来实际优化性能？
选择水平＆＃39;解决方案，是否有建议将列添加到表中？
答案 0 :(得分：2)
我有一个垂直数据库，其中包含2.75亿行＆＃34;值＆＃34;表。我们采用这种方法是因为我们也无法在一开始就准确定义模式。插入物太棒了。选择吮吸。太公平了，我们抛出了几个额外的doohickies，典型的垂直架构并不需要处理。
搜索EAV又称实体属性值模型。你在辩论的双方都会发现很多热情。关于使其有效的文章太多了
我的猜测是这些传感器不会开始向你发送额外的字段。您必须为此发布新的传感器或传感器代码。您有机会对架构进行更改控制并添加额外的列。如果外部各方可以在不通知您的情况下连接传感器，则此参数无效且您可能会遇到EAV。
对于水平选项，您可以拆分将常用列放在一个表中的表，而在一秒表中使用较少的列;两个表都具有相同的主键值，因此您可以将较少使用的列链接到较常用的列。此外，您还可以使用RDBMS的内置分区功能来分割其他人的每一天（或周或月）数据。
答案 1 :(得分：1)
通常，您可以针对插入（或任何DML）或查询更多地调整表。改善一方是以牺牲另一方为代价的。通常，这是一种平衡行为。
首先，每天10K插入并不是一个很大的数字。当然，这并不是微不足道的，但它甚至都没有接近现在被认为是“大”的东西所以，虽然我们不想让插件完全缓慢，但这给你一些摆动空间。
在设备ID和/或条目时间戳上创建索引将为您执行一些逻辑分区。索引的确切构成取决于您的查询。您是否在寻找指定日期或日期范围内的所有条目？然后索引时间戳列。您在寻找从特定设备收到的所有条目吗？然后索引设备ID列。您是在特定日期或日期范围内查找特定设备的条目还是按日期排序？然后在两列上创建索引。
因此，如果您在日期y询问设备x的条目，那么您将前往该表并仅查看您需要的行。表格比您查询的小子集大得多的事实是偶然的。就好像表的其余部分甚至不存在一样。桌子的总大小不一定是令人生畏的。
另一种选择：由于看起来数据被写入表中并且之后从未改变过，因此您可能希望为数据创建数据仓库模式。新条目可以每天或每天多次移动到仓库。关键是，仓库模式可以将数据切片，切块，四分之一和立方体，以使查询更加高效。因此，您可以调整现有表以获得更高效的插入，并调整仓库以获得更高效的查询。毕竟，这是什么数据仓库。
您还暗示每个条目中的一些条目（或可以）从一个条目复制到下一个条目。看看您是否可以将数据分为三种类型：
类型1：永不改变的数据（例如，设备ID）
类型2：很少更改的数据
类型3：经常更改的数据
现在你所拥有的只是一个规范化问题，更容易解决。假设行在类型之间平均分配。所以你有一个包含100行33列的表。而已。它永远不会改变。与之链接的是一个包含至少100行33列的表，但每天可能会添加几行新行。最后，链接到第二个表，一个包含33列行的表，每天可能以10K的速度增长。
这最大限度地减少了在线数据库所需的增长空间。然后仓库可以反规范化回一个巨大的表格以便于查询。