Database 存储过程与.net应用程序中的复杂处理

我们正在使用SQL server数据库在.net 3.5中构建一个新的应用程序。数据库相当大，大约有60个表，其中包含数据负载。net应用程序具有从数据输入和第三方系统将数据带入此数据库的功能

当数据库中的所有数据可用后，系统必须进行大量计算。计算逻辑相当复杂。计算所需的所有数据都在数据库中，输出也需要存储在数据库中。每周都将进行数据收集，每周都需要进行计算，以生成所需的报告

由于上面的场景，我想使用存储过程进行所有这些计算。问题是我们还需要数据独立性，而存储过程将无法提供这一点。但如果我一直在.net中通过查询数据库来完成所有这些工作，我认为它将无法很快完成这项工作

例如，我需要查询一个表，该表将返回2000行，然后对于每一行，我需要查询另一个表，该表将返回300个结果。对于该表的每一行，我需要查询多个表（大约10个），以获取所需数据，进行计算，并将输出存储在另一个表中

现在我的问题是，我是否应该继续使用存储过程解决方案，忘记数据库独立性，因为性能很重要。我还认为，如果我们使用存储过程解决方案，开发时间会少得多。如果任何客户希望在oracle数据库上使用此解决方案（因为他们不想维护另一个数据库），那么我们将存储过程移植到oracle数据库，并为将来的任何更改/增强维护两个版本。类似地，其他客户端可能会要求其他数据库

---

---

我上面提到的2000行是产品SKU。我提到的300行是我们要计算的不同属性，例如处理成本、运输成本等。我提到的10个表包含有关货币换算、单位换算、网络、面积、公司、售价、每天售出数量的信息，结果表将所有信息存储为星型模式，用于分析和报告目的。我们的目标是获取有关产品的任何详细信息，以便了解产品销售的哪些属性花费了我们的钱，以及我们可以在哪里进行改进。

好的，不必详细说明这些表中的数据，仅从餐巾纸计算的后面就可以看出，在您提供的示例中，您正在谈论处理超过600万行的信息（2000行*300行*（1行*10个表））

所有这些行都是不同的，还是10个表的查找信息基数相对较低？换句话说，是否有可能制作一个程序，将10个查找表中的信息存储在内存中，然后只处理内存中的300行结果集以执行计算

---

此外，我还关心可伸缩性——如果在存储过程中执行此操作，则保证它是受单个数据库服务器速度限制的串行进程。如果一个客户端程序可能有多个副本，每个副本处理2000个初始记录集的一块，那么可以并行执行一些计算，可能会加快总体处理时间，当您的初始记录集大10倍时，它也可以扩展。

在C#中编程计算代码之类的东西往往更容易维护。另外，通常将SQL Server上的处理保持在最低限度是一种良好做法，因为数据库是最难扩展的

---

话虽如此，从您的描述来看，存储过程方法似乎是一条出路。当计算代码依赖于大量数据时，将数据移出服务器进行计算的成本会更高。因此，除非你有合理的方法来优化相关数据（例如缓存查找表？），那么你很可能会发现它更痛苦，那么它不值得使用存储的PROC。

< P>我不会考虑在数据库以外的任何地方进行数据操作。 大多数人尝试使用循环算法处理数据库数据。如果您需要真正的速度，请将数据视为一组行，您可以在一次更新中更新数千行。我已经将许多新手程序员编写的游标循环重写为单个更新语句，从而大大缩短了执行时间

你说：

我需要查询一个表，它将 然后为每行返回2000行 我需要查询另一个 将返回300个结果 我需要查询的每一行 多张桌子（约10张）可获得 所需数据

---

从您的问题来看，您似乎没有使用连接，并且您已经在循环中思考了。即使您确实打算循环，也最好编写一个查询来加入所有必要的数据，然后在其上循环。请记住，update和insert语句可能有大量复杂的查询驱动它们。包括CASE语句、派生表、条件联接（左外联接），您几乎可以在一次更新/插入中解决任何问题。

每次都使用存储过程，但正如KM所说，在这些存储过程中，将这些迭代保持在最低限度，也就是说在SQL中使用联接，关系数据库非常擅长连接

数据库的可伸缩性将是一个小问题，特别是因为听起来您将在批处理过程中执行这些计算

除了最琐碎的CRUD应用程序之外，数据库独立性实际上并不存在。因此，如果您最初的需求是使用SQL Server实现这一切，那么请利用RDBMS提供的工具（毕竟，您的客户机将为此花费大量资金）。如果（而且是