关于存储过程的面试问题

Question

您不会在存储过程中存储哪些类型的内容？

Answer 1

这不是关于是否使用存储过程的问题。这是一个假设性的面试问题。面试官希望确信您理解SP不是更适合系统中其他地方的代码和数据的垃圾场。

合理的答案可能包括以下几点：

诸如常量或客户端特定逻辑之类的

• Data永远不属于SPs.
• Passwords或其它安全令牌永远不属于SP或任何code.
• Complex处理可能不适合于当今相当原始的SP逻辑可能更适合于中间层而不是SP，这是由于语言的表达性质、可维护性、OO设计或其它factors.
• Presentation层代码可能最适合于UI，不是SP。

对于像这样的面试问题，目标不是确定一个正确或不正确的答案。相反，面试官在脑海中有他理想的回答，而你的工作是识别那个回答。如果您的面试官是一名DBA，管理一个DBA组，或者看起来他或她自己强烈支持以数据库为中心的方法，那么您可能希望淡化SP语言的弱点，并跳过建议，以避免数据库中复杂的业务逻辑。这些辩论是有时间和地点的，但不是在面试期间！

Answer 2

我认为这是另一个案例，答案是：“视情况而定”。首先，真正要回答的问题可能是：“我计划/愿意将多少业务逻辑转移到数据库？”

这是因为您实际上可以将所有业务逻辑都放在数据库中的存储过程( sprocs )中，而sprocs通常与应用程序的UI或API具有紧密的一对一映射关系。在这种情况下，您可能有名称为LoginUser、ValidateSession、CommitPurchase等的sprocs。

另一方面，您可以让sprocs充当一个精简的数据访问/操作层，真正的业务逻辑位于应用程序框架中的其他位置，而sprocs只是一组美化的CRUD运算符。在这种情况下，您的存储过程名称可能更像GetListOfUsers、GetTop100Users、InsertUser等。

这两种方法各有优缺点，其中一种方法的可行性在很大程度上取决于特定的上下文。以下是关于此主题的一些相关堆栈溢出帖子：

• Business Logic: Database or Application Layer
• Logic: Database or Application/2 (constraints check)
• Business Logic in Database versus Code?

现在，对于您的实际问题，如果您的业务逻辑将位于数据库中，则可能没有不应该(或不可能)位于存储过程中的内容。另一方面，对于类CRUD的sprocs，我认为它们中应该没有任何内容，除非严格需要确保数据的正确性和一致性。

Answer 3

存储过程本身并不存储数据。