Gre*_*ten 3 sql-server stored-procedures
我在使用条件逻辑编写存储过程方面非常缺乏经验,我真的可以使用一些帮助。我有一个包含 7 个表的数据模型,我正在尝试为每个表编写一个允许四个操作的存储过程。每个存储过程都应该有 4 个参数,以允许用户从表中插入、选择、更新和删除记录。我想要一个可以接受这 4 个参数的存储过程,所以我只需要每个表有一个存储过程,而不是 7 个表的 4 个操作有 28 个存储过程。我还没有在网上找到一个关于存储过程中使用的条件逻辑的好例子。你会认为网上会有更多的例子,但仍然很难找到一个好的例子。
有没有办法将条件逻辑 IF 语句添加到存储过程中,因此如果参数是 INSERT,则运行此语句,如果它是 UPDATE,则运行此语句等?
我最近在这个网站上发现了这篇文章:(插入和更新的单独存储过程?)但我不知道如何修改它以包括其他两个选择数据和删除数据的操作。
我附上了我的数据模型以供参考。在此先感谢您的帮助!
小智 15
我强烈建议不要走这条路线。虽然只有 7 个存储过程而不是 28 个存储过程似乎更有利,但它会变成故障排除、调整和维护的噩梦。
我不知道您使用的是什么 dbms,但这些建议应该适用于所有数据库。
从故障排除和使用分析的角度来看,您将遇到困难。您从 dmvs 获得的大多数报告都没有显示用户提交的用于执行存储过程的参数。您将不得不自己捕获它们或运行跟踪以实时查看它。这使得确定这些存储过程的使用方式以及用户使用系统的方式非常困难。他们从数据库中读取的内容是否不仅仅是插入或删除?不深挖就不会知道。如果将它们分解为不同的存储过程,则可以查看使用哪些存储过程的时间和频率。
从可维护性的角度来看,您会认为文件越少越好,但实际上它会使情况变得更糟。现在,每当您想对存储过程的插入部分进行更改时,您都在接触插入、更新和删除的部分,这意味着它们都被添加到回归测试范围内。这也意味着当您部署新的存储过程代码时,您将影响使用该表的人,无论他们在做什么。从调优的角度来看,您实际上是在针对大多数 dbms 查询优化器工作。优化器将查看所需表中的数据,并尝试确定从中检索数据的最佳方式。这里的问题是操作是不可预测的,因为您的操作依赖于参数嗅探。还,1 存储过程规则表的策略做出了一些假设。主要是您选择、插入、更新和删除数据的方式将始终相同。当这种情况发生变化时会发生什么?你不会想继续添加,因为它不容易导航。确定要制作哪些索引也很困难,因为确定优化器将如何反应是极其困难的。
从可用性的角度来看,这让事情变得困难。当您插入时,您需要将每一列作为参数传入,但是当您选择它时,它只会是您要过滤的 id,当您更新时,它可能只是您要更新的列,您必须进行查询了解这个。这通常会导致动态 sql,这是它自己的噩梦。
总而言之,存储过程非常适合做非常具体的事情。大多数情况下,越具体越好。虽然这不会导致代码可重用性和更多要使用的存储过程,但它使故障排除、维护和调整随着应用程序的增长变得更加容易。对于需要使用数据库的开发者来说也更加直观。
如果你确实想走这条路,唯一真正的方法是 if 语句试图根据参数嗅探用户想要做什么:
IF @action = 'insert'
INSERT INTO......
Run Code Online (Sandbox Code Playgroud)
我仍然不会推荐这个。
归档时间: |
|
查看次数: |
11542 次 |
最近记录: |