我正在编写一个可以使用相当大的数据库的新软件。该软件将从许多尺度捕获数据，这将向软件发送许多权重值。每个刻度都有一个序列号。
考虑每一行的基本信息，即weight_id，scale_id，weight和timestamp ......是一个唯一的表，它会有一个名为scale_id的列，还是每个比例的表更好？考虑到我们不能有太多的尺度...最大数量将是16 ...更常见3-4。
案例A. 独特的表格
案例B. 表scale_1123，表scale_2222
我对这个问题有疑问，因为我们希望每个规模的行数每年可达到100.000.000 ......并且机器可以运行长达10年......或许更多。< / p>
最后，我应该按月或按周打破桌子吗？或者我可以把它们放在一起吗？
我们的目标是 - 当我们拥有一个大型数据库时 - 在特定时间范围内进行查询，以便在最短的时间内提取一个或多个量表的统计数据（如平均体重，STD。偏差，......）< / p>
我很抱歉这些问题......但是阅读数据库文档我找不到哪个是最好的答案
答案 0 :(得分：3)
阅读数据库文档我无法找到最佳答案
数据库文档告知您如何使用该产品，它没有告知您如何设计数据库。为此，你需要接受教育。
该平台尚未定义......因此我们在此阶段具有灵活性
嗯，最重要的建议是，获得一个真正的SQL平台（即一个符合ISO / IEC / ANSI SQL标准的平台），你赢了;当你从假装中迁移时必须重写你的代码 - sql或非sql到真正的SQL。这些天有很多免费软件/共享软件/ vapourware，都是不合规的，所有这些都是通过引用＆＃34; SQL＆＃34;在手册中，在每一页上，但它们都是欺诈行为。他们有许多额外的东西，但他们缺乏基础。
你总能得到你付出的代价，所以要确保你付出一些有价值的东西，以获得有价值的东西。商业SQL（Oracle除外）具有服务器架构，它们比vapourware快三个数量级。
在IT的这些黑暗时期，趋势似乎是：
关注数据，尤其是数据值。这为您提供了一个很好的电子表格视角
在每个文件上标记ID字段。这样就可以修复电子表格。
在某个非SQL平台的数据库容器中实现它。
编写应用
期待它的任何和所有关系数据库功能。
现在，在上述步骤中，确切地说是使用关系数据库原则;造型;设计;正常化;等？在什么基础上，任何理性的人都可以期待任何关系能力（更不用说Integrity; Power;或Speed）？那件事如何获得关系能力？
如果你把一袋垃圾放在标有＆＃34;瑞士巧克力 Top Quailty ＆＃34;的盒子里，它仍然是垃圾。这个位置并没有将垃圾神奇地转化为瑞士巧克力。
重点是双重的：
如果你没有自己教育关系数据库技术，和应用它，那么这个东西就不会是关系型的。
上述步骤的结果始终是1970年以前的ISAM记录归档系统。没有关系数据库的完整性，功能或速度。
现在你一直在读书。好。但问题在于，所有关于关系数据库的书籍都是由完全不了解它的人写的。自从我们拥有真正的RDBMS平台34年以来，E F Codd博士写了 Relational Model 已经过去了45年;标准;方法，但地球的95％仍在实施1970年以前的ISAM RFS。为什么？因为这就是书籍所教导的内容。为什么？因为这是所有作者真正知道的。他们无法教授他们不知道的事情。
你是一个聪明能干的人，但你被颠覆了。所以必须先纠正。请阅读this Answer。慢慢来。实际上使用并试验给出的示例SQL代码。
两个总结点。如果您在电子表格的数据透视图上标记了ID：
这将是一个RFS，而不是一个RDb。
这将削弱建模过程。
但是你已经用数据库，性能，优化标记了你的问题，所以我假设你想要所有这些。
瑞士牛奶和最好的可可制作瑞士巧克力。为了生成关系数据库，必须
为数据建模，只为数据建模，只为数据建模。这意味着没有引用用法，应用程序或报告
使用关系数据建模技术和规范化
确定关系密钥（这就是完整性，功能和速度的来源）
了解数据库是一系列事实，关于应用程序将要使用的真实世界。它不是具有可能相关的字段的记录集合（这是电子表格的透视图）。
这将生成一个真正的关系数据库，其中任何报告都可以在单个SELECT命令中写入数据。选择你梦寐以求的，以及你无法想象的SELECT。
目标是 - 当我们拥有一个大型数据库时 - 在特定时间范围内进行查询，以便在最短的时间内提取一个或多个量表的统计数据（如平均权重，STD。偏差，... 。）
这只是你可以梦想的SELECT的一些例子，现在。它们都不复杂，每个都可以使用单个SELECT生成。来自RDb。从RFS开始，编写代码需要大约10倍的时间，并且需要多次迭代才能获得正确的数据。它至少需要10倍的硬件资源。
方法是，首先我们做对了。这意味着Relational，非常非常快，可以处理数十亿行。然后，当且仅在必要时，我们使用真正的方法来提高性能。这是一个歇斯底里的神话，人们可以在不正确的事情上实现性能。
最好是一个唯一的表，它有一个名为scale_id的列，或者每个比例的表更好吗？
最后，我应该按月或按周打破这些表吗？
丑恶。
从不＆＃34;休息＆＃34;一张桌子。
你可能很乐意为它编码，在一个地方看两个地方或16个地方，但没有其他人会。离开项目后，用户很久就会诅咒你。这是1960年以前的方法论。我们在1969年把人放在月球上。这是2015年。我们现在用GB说话，而不是KB，而不是MB。
考虑每一行的基本信息，即weight_id，scale_id，weight和timestamp
不幸的是，这不是数据，这是上述非关系步骤的结果，包括所有类型的多余非数据。在我们考虑之前，我们必须首先正确建模数据。
您尚未发布来自比例的传入数据。我会假设：
serial_no
date_time -- time_stamp is misleading
weight
不知何故，在某个地方，你会被告知被称重的是什么，而不是通过那个饲料。
如果通过Feed输入了其他内容，请立即告诉我。可能必须记录诸如ScaleReset之类的项目。
案例A唯一表 案例B表scale_1123，表scale_2222
好的，所以选项B似乎是每个比例一个表。可怕。你能想象跨越规模的标准偏差所需的SELECT。写这些书的人应该把它放在一个庇护所。
其次，它过早地担心表现。
好的，在这种情况下，选项A＆＃34;唯一表＆＃34; （这使我感到困惑，因为所有关系表都是唯一的，它们具有唯一的行）似乎是一个表中的所有比例，除了无用且误导性的ID字段之外，这更正确。
考虑到我们不能有太多的量表...最大数量将是16 ...更常见的是3-4。
无论如何都没有任何区别。系统可能会增长，您可能会有很多客户。
我对这个问题表示怀疑，因为我们希望每个规模的行数每年可以达到100.000.000 ......并且这些机器可以运行长达10年。 .maybe more。
无论如何都没有任何区别。系统可能会增长，您可能拥有许多客户。在确定性能问题之前，过早地担心性能问题。首先我们做对了，然后我们把它做得更快。
在关系数据库中无需担心每个规模每秒3.17次插入。你应该担心的是你没有一个，你有一个RFS。这将在负载下破裂。然后你将不得不执行各种各样的杂技，以改善＆＃34;负面表现。最好将数据放入RDb。
16个Billon行对于真正的SQL平台来说没问题。如果不是更早的话，假装-sllls将自己约为20亿行。
这是所需的数据模型。
如果您不习惯乐谱，请注意每个小刻度，刻痕和标记，实线与虚线，方形与圆角，意味着非常具体。仔细阅读IDEF1X Notation。
请仔细检查谓词。它们在验证模型时非常重要。如果不清楚，请询问。
每个刻度都有一个序列号。没有更好的唯一行标识符。
在历史表中，DateTime是要添加的明显组件，为了形成唯一性，它位于数据中（密钥可以由数据组成）。
不需要ID个字段。如果你把它们放入，它们将是（a）多余的（b）额外的索引（c）增加插入性能的负担。
密钥均匀分配数据。这意味着高并发性，因为并发插入（每秒3.12，时间4到16个刻度）将在表中传播，没有冲突。
相反，＆＃34; PK＆＃34;这是一个ID字段，保证所有并发插入都会发生冲突，因为它们必须写入最后一页。这是一个有保证的热点＆＃34;。
只能在真正的SQL平台上传播插入加载。在PK上使用聚集索引。
但是，如果管理不当，则会导致页面拆分。该方法是根据索引重建的频率设置合适的FILLFACTOR。 （例如，我每三年重建一次Clustered Indices，并且仅使用最大的表格，超过50GB，使用80％的FILLFACTOR，留下20％用于插入插入。小于此的表格从不需要重建首先重建。）
备用密钥的目的是在所有规模上提供DateTime的即时访问，即。你的时间范围查询。一个等级内的时间范围查询将使用PK索引，而不是AK索引，它们也将是瞬时的。
ID个字段，请分开以保证插入＆＃34;热点＆＃34;上的连续冲突，您的所有查询都将是＆＃34;跳跃＆＃34;整个文件。答案 1 :(得分：1)
你的问题实际上与这个类型的大多数问题有点不同，但我认为这不会改变答案。通用答案是“将它们全部存储在一个表中，并使用分区和索引来获得所需的性能。”
但是，您说的是每个规模每年100,000,000行。拥有10年和16个等级，即高达16,000,000,000行。将scale id包括为4字节整数（相对于将数据存储在不同的表中）意味着额外增加64 GB的存储空间。这不是微不足道的，但是，当然，在10年的时间内，这似乎要少得多。
我无法回答你的问题（尽管我有偏见），但这是你应该考虑的事情：
除了你建议的两个数据之外，这个数据量还有许多可能的架构：
而且，我认为这个清单还在继续。