存储过程与视图

好吧,我会更好地使用存储过程来封装代码和控制权限。

视图不是真正的封装:它是一个扩展的宏。如果你很快就开始加入视图,你会有一些可怕的问题。是的,他们 可以 但他们不应该加入。

也就是说,视图是一个工具,其位置(例如索引视图)与存储过程类似。

视图的优点是它们可以像表一样被处理。你可以在哪里从他们那里获得过滤数据,加入他们,等等。如果数据足够简单,您甚至可以在其中插入数据。视图还允许您索引它们的结果,与存储过程不同。

一个视图就像一个保存的查询语句,它不能包含复杂的逻辑或多个语句(不使用union等)。对于任何复杂或可通过参数定制的内容,您可以选择允许更大灵活性的存储过程。

在数据库体系结构中使用视图和存储过程的组合是很常见的,可能是因为非常不同的原因。有时,当模式被重新设计时,它会在存储过程中实现向后兼容性,有时会使数据比存储在表中的方式(去noramlized视图)更易于操作。

大量使用视图会降低性能,因为SQL Server更难优化这些查询。但是,在使用与索引表相同的联接时,可以使用索引视图,这实际上可以提高性能。在实现索引视图时,对所允许的语法有更严格的限制,并且在实际使它们工作时有许多微妙之处,这取决于SQL Server的版本。

将视图视为更像表而不是存储过程。

存储过程的主要优点是它们允许您合并逻辑(脚本)。这个逻辑可能和if/else一样简单,或者更复杂,比如do-while循环、switch/case。

我将存储过程的使用与向数据库发送/接收事务的需要关联起来。也就是说,每当我需要向数据库发送数据时,我都使用一个存储过程。当我想更新数据或查询数据库以获取在我的应用程序中使用的信息时,也是如此。

当您希望提供给定表中字段的子集时,可以使用数据库视图,允许MS Access用户查看数据,而不存在修改数据的风险,并确保您的报告将生成预期的结果。

如果表的某个组合或您一直想要查询的数据的子集(例如,具有其权限的用户),则视图非常有用。实际上,视图应该被视为表。

存储过程是“编译”的SQL代码片段,在这里,它比随机的其他查询运行得更好。存储过程中的SQL代码的执行计划已经构建好了,因此执行比普通的SQL语句要稍微平稳一些。

两个基本原理。

如果不希望插入,请使用存储过程而不是视图。在视图中插入可能无法给出它所做的事情。它将插入一个表中,一个可能与视图中的查询不匹配的行,一个随后不会出现在视图中的行;插入到某个位置,但不插入语句使其看起来的位置。

如果不能使用另一个存储过程的存储过程的结果,请使用视图(我无法使后者工作,至少使用MySQL)。