0

我一直认为 SQL 编译器会崩溃，但显然嵌套几乎是无限的。这段代码是要立即丢弃还是有一线希望这样的东西可以运行？

这个查询并不真正属于我，所以我不能发布它......但是让我们假装它是这个：

[SELECT /*+ NOPARALLEL bypass_recursive_check */ 
SP_ALIAS_190, 
((CASE SP_ALIAS_191
WHEN 1
THEN 'PROVIDER::ALL_PROV::'
WHEN 0]
4

8 回答 8

8

显然，您从未见过从 Sharepoint DAL 产生的 SQL。

于 2009-04-29T02:20:44.050 回答
7

如果查询是由工具（或代码）生成的，那么维护起来可能相对简单（从某种意义上说，查询生成代码实际上可能编写得很好并且可维护）

于 2009-04-29T02:30:16.010 回答
2

我最近遇到了类似的问题，我通过考虑几件事做出了决定：

  • 维护与重写需要多长时间？
  • 这有多重要？可能有很多逻辑可能难以解开，并且“它有效”这一事实的价值超过了立即重写的价值。

当然，管理层必须做出有关冒险解释为什么必须重写最近创建的东西的政治决策。

最后（对我来说），find + replace 是我的朋友。

于 2009-04-29T02:24:48.503 回答
1

使用WITH语句重构它。添加很多很多很多评论。

如果你把它分解成可以管理的部分，你就有更好的机会。

于 2009-04-29T02:32:46.707 回答
1

如果它包含嵌套分配，我会说不。

就像任何代码一样，无论是什么语言，你都应该只考虑重写它，因为你可以让它更高效或更容易理解。

根据我的经验，我已经能够将编写不好的 SQL 减少 4 到 5 倍的大小和许多倍的性能，因为原始作者真的不知道。

于 2009-04-29T02:47:42.800 回答
1

如果您认为这很糟糕，您应该观看 Industrial Logic 关于代码异味的示例视频：技术债务。绝对不是自动生成的。

于 2009-04-29T02:48:19.117 回答
0

是否可以在 C# 中维护 43 页功能？答案很明显;)。我只是无法想象这一点。如果我是你，我会把它分成更小的部分。

于 2009-04-29T02:25:02.760 回答
0

两件事情：

  • 只有机器需要读取这个 SQL 吗？
  • 您是否坚持底层架构？

如果您有一个 43 页的查询并且您对前两个问题的回答是肯定的，欢迎来到 SharePoint 开发

于 2009-04-29T04:41:34.213 回答