我如何'重构'SQL查询？

Question

我有几个MS Access查询（在视图和存储过程中）我转换为SQL Server 2000（T-SQL）。由于Access有关子查询的限制，以及原始开发人员的限制，因此创建了许多仅作为其他视图的子查询的视图。

我没有明确的业务需求规范，除了“执行Access应用程序的功能”，以及有关报告/ CSV提取的半页说明，但Access应用程序甚至没有做我怀疑的要求得当。

因此，我必须采用自下而上的方法，并将Access DB“复制”到T-SQL，在那里我通常会更好地理解需求并采用自上而下的方法，创建新的查询以满足定义的要求。

我可以遵循这样做的方法吗？我是否将它全部展开并花了几天时间“gro，”，还是继续只是复制Access视图并采用渐进方法来优化查询？

Answer 1

我可能从Access数据库开始，在原地运行查询并查看结果集是什么。通常，您可以了解查询完成的内容，然后回溯到您自己的设计来完成它。 （要彻底，你需要完全理解这个意图。）这听起来像是你要获得的最佳要求 - “就像它现在已经实现的那样。”

除此之外，你的方法是我能想到的最好的方法。一旦他们进入SQL Server，就开始测试和grokking。

Answer 2

当您处理这样的问题时，在进行增量更改时保持工作正常是有帮助的。从风险管理的角度来看，这样做会更好。

我专注于让它工作，然后检查数据库性能并优化性能问题。然后，当您添加功能并修复错误时，请清理难以维护的代码。正如您所说，子查询与视图非常相似。因此，如果它没有被破坏，你可能不需要改变它。

Answer 3

计算对查询的访问权限，然后使用此知识检查您是否已正确传输它。只有在你完成这项工作后才能考虑重构。我从慢查询开始，然后从那里开始：找出你需要的索引，然后逐步重写。这样一旦你证明你成功地移动了所有东西（即使它可能有点慢），你就可以交付。由于问题X出现，这比完全无法交付要好得多。

Answer 4

这取决于您的时间表。如果你必须尽快让项目运行（我知道这对于每个项目都是如此，但如果它真的对你来说是真的），那么是的，从Access复制功能和基础设施然后再进行重构或者作为重构你走了。

如果你有一些时间可以专注于它，那么现在重构它会给你两件事：

1. 你会对代码感到满意，并且它（可能）表现得更好，因为实际分析已经完成而不是转码等同于复制粘贴
2. 您可能会更加了解真正的业务规则，因为您几乎肯定会遇到规范中没有的内容（特别是考虑您如何描述它们）。

Answer 5

我建议立即将视图复制到SQL Server，然后使用其复杂的工具来帮助您理解它们。

例如，SQL Server可以告诉您哪些视图，存储过程等依赖于特定视图，因此您可以从那里看到视图是单一视图还是实际在多个位置使用。它将帮助您确定哪些视图比哪些视图更重要。