【问题标题】:Converting inline SQL to stored procedure将内联 SQL 转换为存储过程
【发布时间】:2014-08-29 17:59:05
【问题描述】:

我正在开发一个现有的 ASP.NET 应用程序。当前应用程序使用了大量的内联查询。现在他们只想将所有查询重写为存储过程。

我的问题是,这些查询非常“动态”,并且查询是根据不同的if...else 条件连接起来的,例如:

string query = "Select * from EmpTable WHERE EmpType ='ACTIVE'";

if (conditionA == true)
query += "AND ID = 12345 ";

if (conditionB == true)
query += "AND Dept = 'Finance' ";

else
query += "AND Dept <> 'Finance' ";

if (conditionC == true)
query += "Order by EmpID";

else if (ConditionD == true)
query += "Order by Dept";

他们还希望避免使用动态查询。我有哪些选择?

已编辑:我知道我也可以使用存储过程构建动态查询,我只是想知道还有哪些其他“不那么痛苦”的选项。

【问题讨论】:

  • 维护噩梦
  • 好吧,您可以将条件作为参数传递给 SP 并在那里构建动态 SQL。不是最好的方法,但最不痛苦
  • 如果处理得当,动态查询可以与静态查询一样高效。或许“他们”只有编写糟糕的动态 SQL 的经验。
  • 如果这绝对肯定是存储过程,是否可以在客户端创建多个过程和条件语句?对于这种情况,我不建议使用存储过程,但我知道一旦他们学习了一项新技术,管理会如何。
  • 您是否考虑过为您的存储过程使用默认参数值?然后,您可以从 .NET 代码中为参数值传递 null,SQL 将忽略 NULL 并使用参数默认值。不涉及条件逻辑。

标签: asp.net sql-server stored-procedures


【解决方案1】:

传入您可能需要的所有参数,并使用IsNull 和/或When 子句创建与原始程序中相同的查询。

或者,您可以简单地在存储过程本身中动态构建查询,或者简单地为每个排列创建一个查询。不一定有趣或聪明,但可以工作并使事情在未来更易于维护 - 特别是当您可以将其用作未来重构存储过程的垫脚石时。

编辑:还有一个简单的理由将它们全部转换为存储过程 - 当未来的开发人员出现并想要添加一些 SQL 时,他们将遵循约定并自己创建一个新的存储过程。我想您的代码中充斥着动态 SQL 的一个原因是因为它已经充斥着动态 SQL。也许随着时间的推移,你可以改进它们(在每个转换的顶部拍legacy,必须修复),你也会让他们自己修复设计。

【讨论】:

  • 我想这是我目前唯一的选择
  • @C.J.这不是最优雅的解决方案,但考虑到您的要求,我觉得 gbjbaanb 的解决方案绝对是您应该寻找的地方。尤其是第二段的可维护性。
  • +1 用于为每个排列编写单独的过程。维护 5 个简单的程序通常比维护执行 5 个功能的单个程序更容易/更省时,并且更改其中一个功能可能会破坏其他功能。更不用说您为使所有 5 个函数在同一过程中工作而实现的体操,未来负责维护它的开发人员可能无法阅读。
  • +1 用于单独的程序。建议的解决方案将执行得非常糟糕。 SQL Server 不喜欢通用代码。复制代码更难维护,但它会比在 WHERE 子句中使用条件逻辑更好地实现跨越式发展。如果您必须使用动态 SQL,则在过程中动态构建字符串,从长远来看,它的性能会更好。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-10-10
  • 2021-08-17
  • 1970-01-01
  • 1970-01-01
  • 2020-06-06
  • 1970-01-01
相关资源
最近更新 更多