我们的应用程序（使用SQL Server 2008 R2后端）存储有关通过Internet向我们的服务器报告的远程硬件设备的数据。我们有关于每个设备的一些信息“系列”，每个设备都由不同的服务器应用程序存储到共享数据库中：
这些属性都是标量值，反映了我们对设备的最新数据。我们有一个单独的方式来存储历史信息。
我们不得不担心的设备实例数量最多，大约为100,000，因此这不是一个“大数据”问题。在大多数情况下，数据库将需要10,000个或更少的设备担心。
写入有关单个设备的数据不经常发生 - 通常每隔几个小时发生一次。从理论上讲，计划任务，用户输入的配置更改以及动态数据都可以同时为同一设备进行更新，但这似乎非常罕见。读取更频繁：对于数据库中的至少一个设备，可能每分钟读取10次，对数据库中描述的所有设备的某些属性进行全面扫描，每小时读取几次。
删除相对较少，事实上很多情况下我们只是“软删除”设备，因此我们可以将它们用于历史报告。新设备插件更常见，可能每天都有一些。
（至少）有两种显而易见的方法可以将这些数据存储在我们的SQL数据库中：
我的问题：有一个明显优越的选择吗？如果答案是“它取决于”那么什么情况会使“一个大表”或“多个表”更好？
答案应该考虑：数据库本身的性能，可维护性，读取/写入行的代码的可维护性以及面对意外行为时的可靠性。如果我们不得不进行权衡，那么可维护性和可靠性对我们来说可能比性能更重要。
答案 0 :(得分：1)
不知道一个明显优越的选项，我不知道sql-server架构。但我会为不同的数据系列提供单独的表格的第一个选项。一些优点可能是：
授予对特定数据集的访问权限（可能适用于未来的应用程序）
以不同的费率存档不同的数据错误
在部件维护的情况下应用程序的部分功能（某些表可用而另一些表已恢复）
索引和分区/分片可以在不同的属性上执行（静态信息可以在设备ID上分区，在日期记录信息）
可以将不同的族分配到不同的缓存区域（因此静态数据可以保留在更“静态”的缓存中，更快速更改的日志记录类型数据可以在另一个“滚动”缓存区域中）
较小的行将更多行打包到一个块中，这意味着更少的块拉动来扫描特定属性的表
如果改变一个表来添加一行，更容易进行行链接，如果你这样做就更容易执行维护
在分成逻辑单元（系列）时更容易理解数据
在正确索引时，我不认为表连接是一个缺点。但是更多的表格意味着更多的移动部件以及需要更多的意识/记录正在发生的事情。
答案 1 :(得分：0)
第一个选项是在关系数据库中存储此类数据的公认“标准”方法。 虽然好的设计可能会导致更多表。关系数据库软件（如SQLServer）旨在快速有效地在多个表中存储和检索数据。
此外，这些设计在更改数据库以存储额外数据方面具有很大的灵活性，并允许对存储的数据进行意外/异常查询。
对于不熟悉Relational数据库的从业者来说，单表选项听起来很简单。在实践中，它们表现非常糟糕，难以管理，并导致大量死锁和超时。
他们也导致发展瘫痪。您无法添加所请求的功能，因为如果不重新设计“简单”数据库架构，就无法完成。