以下是一个好方法：
每周，大约250,000个表示事务的记录将附加到SQL 2005数据库中的大表中。需要增加此数据并将其附加到另一个表中。 （例如，基于事务上的客户端ID，将根据某些业务规则计算各种数据;数据取决于客户端ID和事务ID。）将此表视为分析引擎的预处理输入。然后，此输入数据将通过分析引擎（供应商解决方案），该分析引擎将生成第三个数据库表。然后，该表将需要进一步处理（例如，通过客户端ID和一些内部分析的聚合）附加到包含我们团队可用于报告生成的表单的结果的表中。未来相同的数据可能会提供给其他应用程序，例如基于Web的数据查看器。
我们的技能基础是C，C ++，C＃，.NET，熟悉ADO.NET和LINQ。如果这还不适合这样的项目，请告诉我。虽然我们现在对新人才的预算不存在，但我们可能会努力提高我们的内部技能基础，或者借用其他团队来满足项目要求。
答案 0 :(得分：3)
根据您的描述，这听起来应该完全通过数据库驱动，例如使用T-SQL和SSIS。加载到表格和pre＆amp;后处理（聚合，后续加载等）是SSIS将发挥作用的地方。如果我错过了意图，请告诉我。
答案 1 :(得分：2)
我现在正在阅读关于尺寸建模，星型图案和数据仓库的文章，所以请原谅我在学习锤子后看到钉子。我会问你手边是否有一个好的数据建模器。我非常喜欢Ralph Kimball关于尺寸建模的想法。我敢打赌供应商报告解决方案会直接插入。在我看来，事务和报告模式之间的任务差异需要不同的方法。
答案 2 :(得分：0)
这听起来像是ETL项目。您想使用SQL Server集成服务。它是SQL 2000中DTS的替代品。
答案 3 :(得分：0)
数据库操作是S ... L ... O ... W ...
您将内容放入数据库中进行查询。
因此，您的中间结果不适合数据库存储。
“代表交易的250,000条记录......需要增加此数据......根据交易中的客户ID，将根据某些业务规则计算各种数据;数据取决于客户机ID和交易ID。“
前几个操作不会导致您要查询的数据。您只是将其暂存在数据库中。这是（1）慢和（2）不是很有帮助。只需将其留在文件中即可完成所有这些扩充处理。
将文件放在可以备份的目录中，就像进行数据库备份一样，你会没事的。
由于你的设计看起来很好，所以你可以做的就是。但是，如果您的数据库设计非常灵活，请查看Kimball的数据仓库工具包，您会看到当您拥有依赖于客户端ID的字段时，这实际上意味着您拥有客户端维度。
定义客户表。使用事实和维度之间的简单连接来定位客户端数据。
这种维度查找技术适用于所有这些“数据增强”操作。因此，在“数据增强”中几乎没有实际的处理过程。
通常，您会弄清楚如何将传入事务的键与您定义的维度进行匹配。有时尺寸值已经改变;有时您需要添加新的维度值。因此，您的“扩充”将转移到检查维度，并为每个传入记录附加一些键。然后使用适当的度量和外键将事实表加载到维度。