数据集V/S数据库

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

因为有时您需要在将数据返回到客户机之前做一些处理,当您只需要一个子集时返回一堆行是浪费的。例如,当必须涉及临时表或链接服务器时,在存储过程中执行一些复杂的操作也比较容易。

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

如果你有一个GB的数据库 数据跨越一堆表 想找个简单的客户 记录并加入他们的命令,是吗? 让客户满意是有道理的 应用程序或Web服务器的GB数据 拿到你正在找的1千字节 为了什么?

您希望最小化传递到应用程序层的数据量。您还希望让数据的处理在尽可能快的地方完成。将其存储在数据集中不会给您提供索引和全文搜索选项等。我们使用数据库来存储和检索数据或其他简单的平面文件(我们在启动时加载到内存中)是唯一需要的。如果你的应用程序和数据很小,那么这可能是一个替代方案,但在大多数情况下不是。

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

我想应该在更有意义的地方进行处理。

例如,如果您的应用程序有一个过程,它需要的来自应用程序的输入更少,而来自数据库的输入更多,那么最好在数据库级别完成。

它还取决于您试图在数据库级别对这些内容进行的操作和支持。
示例:正则表达式或数学函数的用法。

我们能从数据库获取所有数据吗? 将其存储在数据集中,然后处理 是吗?表演什么 这个场景中的应用程序?

我认为将数据库中的所有数据存入应用程序内存是不合理的。
答案取决于数据的多少?它经常改变吗?如果数据库中的数据发生变化,应用程序的行为如何?

一般来说,如果您有某种静态数据,可以将其保存在应用程序内存中,而不是其他情况。

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

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

两种模式都存在。

如果您需要进行认真的数学和字符串操作,或者矩阵数学,那么您可能最终会将大量的DB拖到内存中。

如果您所做的工作有一个可以用join和where子句来解决的解决方案,那么SQL就是合适的地方,即使您可以从哲学上论证它可以被归类为业务逻辑。将基于集合的逻辑转移到中间层很可能会导致中间层关系数据库的重新发明,而且这不会做得很好!

当行数非常小(并且总是很小)时,这并不重要。SQL是一个相当贫穷的编程语言相比,C或Java,当涉及到单元测试,工具支持等,所以如果你有100行在你的数据库(永远不会有更多!)然后,无论如何,可以随意地将它们放入内存中的数据结构中——即使在那里,数据库在排序之类的领域仍然会更高效、更不容易出错。