是否可以维护 43 页查询？ [关闭]答案

【问题标题】：Is it possible to maintain a 43 page query? [closed]是否可以维护 43 页查询？ [关闭]
【发布时间】：2009-04-29 02:18:36
【问题描述】：

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

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

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

【问题讨论】：

【解决方案1】：

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

【讨论】：

更大吗？亲爱的主……这让我想到可能这是生成的……
是的。但是你得罪了一个人。无论如何 +1 回到 0。
Sharepoint::SQL as Word::HTML
我将讲一个简短的故事来说明：我们的 SP 场的数据库集群遇到了严重的死锁。高级 MS DBA 被请来诊断 SQL Server，但不知道我们正在运行 SP。她发现了令人反感的问题并惊呼“这到底是什么？当然你有这些问题”，认为这是我们写的东西。我们告诉她那来自SP。她什么也没说。
不是说SharePoint DAL永远不会有什么好事吗？

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

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

最后（对我而言），find + replace 是我的朋友。

【讨论】：

【解决方案4】：

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

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

【讨论】：

【解决方案5】：

如果它包含嵌套分配，我会拒绝。

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

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

【讨论】：

【解决方案6】：

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

【讨论】：

【解决方案7】：

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

【讨论】：

【解决方案8】：

两件事：

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

【讨论】：