附加列与其他行的性能

我对表格设计和性能有疑问。我有许多分析机器产生不同数量的数据（这些数据已经通过运行机器的dos程序存储在文本文件中）。我决定更新并创建一个新的数据库来存储所有机器的结果。我已经创建了单独的表来存储结果的类型，例如，从平衡机的所有查询结果存储在天平结果表等附加列与其他行的性能

我对每个机器是一个共同的结果表的格式如下：

ClientRequestID PK 
SampleNumber  PK 
MeasureDtTm 
Operator 
AnalyteName 
UnitOfMeasure 
Value

一个典型的ClientRequest可能有50个样本这就需要由各种机器进行测试。每台机器每个样品只记录1行，因此每个表的apprx 50行与任何给定的ClientRequest相关联。

这适用于除一个机器外的所有机器！它可以测量每个样品20-30个分析物（并将它们排出一个长排），而所有其他机器，我只需要为每个RequestID/SampleNumber测量1个分析物。如果我坚持这种格式，这台机器每年将产生超过百万行，因为每个样本可以有多达30个测量值。我的其他表格每年只能以3000-5000行的速度增长。

所以在这一切之后，我的问题是这样的：

我是更好地坚持该表的通用格式，并有排斗载荷，或者是它更好地只是添加额外的列来表示每个分析物，这样每个样品只会产生一行（与其他表格一样）。该机器最多只能测量30个分析物（每台机器25万美元，我赢了;在我的生命中获得另一台机器）。

我很担心的是报告性能和在线编辑。在这两种情况下，PK：RequestID和SampleNumber保持不变，所以我想这只是一个加载更快的问题。我知道从设计的角度来看，多列方法被认为是可悲的，但是在这种情况下它会产生更好的性能吗？

BTW数据库是MS的Jet/Access 2010中

任何帮助将不胜感激！

来源

2010-07-29 James

“BTW数据库是MS的Jet/Access 2010中的” 这是你的问题的80％。使用几乎任何ODBC数据库，您就可以与性能和空间利用率更快乐。 – 2010-07-29 23:41:31

您可以从“共同作用的结果”表解耦AnalyteName柱：

-- Table Common Results 

ClientRequestID PK SampleNumber PK MeasureDtTm Operator UnitOfMeasure Value 

-- Table Results Analyte 

ClientRequestID PK SampleNumber PK AnalyteName

您加入的PK（请求+样品。）这样，你不要无谓地重复行的所有其余可以避免在不需要使用AnalyteName的查询中进行连接，可以支持额外的Analytes，并且总体上更加安全。除非你真的开始出现性能问题，否则这是我遵循的方法。

即使您开始出现性能问题，我也会首先转到真正的数据库，以查看在将列添加到结果表之前是否解决了问题。

来源

2010-07-29 23:48:11

如果行数很少，那么Jet/ACE数据库中的数百万行并不是问题。

但是，我担心的是如何插入这些记录 - 这是实时数据收集吗？如果是的话，我建议这可能是比喷气多/ ACE能够可靠地处理。

我是一个有经验的开发人员访问是谁的Jet/ACE的忠实粉丝，但是从我了解你的项目，如果我开始出来，我肯定会选择从一开始走的服务器数据库，不是因为Jet/ACE可能现在不能处理它，而是因为我在10年的历程的角度思考，当这个程序可能仍然在使用（记得2000年，这主要是被设计的应用程序的问题计划报废，但从未取代）。

来源

2010-07-30 19:32:16

附加列与其他行的性能

回答

相关问题