DataSet v / s数据库

Question

在设计应用程序时，将所有业务逻辑集中在一个地方是一种非常好的做法。那么为什么我们有时会在存储过程中拥有业务逻辑呢？我们可以从数据库中获取所有数据并将其存储在DataSet中然后进行处理吗？在这种情况下，应用程序的性能如何？

Answer 1

  

那么为什么我们有时会在存储过程中拥有业务逻辑呢？

因为有时你需要在将数据返回给客户端之前进行一些处理，当你只需要一个子集时返回一堆行是浪费的。当你必须涉及临时表或链接服务器时，例如

，在存储过程中也会更容易做一些复杂的事情

Answer 2

想想这个基本的例子，它应该回答你的问题：

  

如果你有一个GB的数据库   跨越一堆表和你的数据   想得到一个简单的客户   记录并加入他们的订单，是吗？   有意义地带回客户端   应用程序或Web服务器只有GB的数据   得到你实际看的1KB   为？

您希望最小化传递到应用程序层的数据量。您还希望在尽可能快的地方完成对数据的处理。将它存储在数据集中不会为您提供索引和全文搜索选项等。我们使用数据库来存储和检索数据是有原因的，否则我们在启动时加载到内存中的简单平面文件将是所有需要的。如果您的应用和数据很小，那么这可能是一种替代方案，但在大多数情况下并非如此。

Answer 3

  

那么为什么我们有时会有   存储过程中的业务逻辑？

我想应该完成处理，它更有意义。

例如，如果您的应用程序有一些进程需要较少的来自应用程序的输入＆amp;更多来自数据库，最好在数据库级别完成。

这还取决于你要做的事情＆amp;在数据库级别支持此类事情 示例：使用正则表达式或数学函数。

  

我们可以从数据库中获取所有数据吗？   将其存储在DataSet中然后进行处理   它？会有什么表现   这个场景中的应用程序？

我认为将数据库中的所有数据都存入应用程序内存是不合理的 答案取决于数据的数量？它经常变化吗？如果数据库中的数据发生变化，您的应用程序将如何运作？

一般情况下，如果你有某种静态数据，可以将它放在应用程序内存中。不然的。

Answer 4

  

那么为什么我们有时会在存储过程中拥有业务逻辑呢？

另一个重要原因是安全性。您可能希望通过在存储过程中实现代码来监视对数据的访问（尤其是写访问）。这样，所有对数据的访问都通过存储过程进行隧道传输，并且可以防止可疑访问

Answer 5

两种模式都存在。

如果您需要进行严格的数学运算和字符串处理或矩阵数学运算，最终可能会将大量的数据库拉入内存。

如果你的工作有一个可以通过join和where子句解决的解决方案，那么SQL就是适合它的地方，即使有人可以做出一个可以归类为业务逻辑的哲学论证。将基于集合的逻辑移动到中间层可能会导致在中间层重新发明关系数据库，并且它不会很好地完成！

当行数非常小（并且总是如此）时，它并不重要。与C＃或java相比，SQL在单元测试，工具支持等方面是一种相当贫困的编程语言，所以如果你的数据库中有100行（并且永远不会有更多！），那么无论如何，请随意将它们放入内存数据结构中 - 尽管在那里，数据库在排序等方面仍然会更有效率和更少的错误。