我有几个要转换为 SQL Server 2000 (T-SQL) 的 MS Access 查询（在视图和存储过程中）。由于 Access 对子查询的限制，以及/或原始开发人员的限制，已创建了许多仅用作其他视图的子查询的视图。
我没有明确的业务需求规范，除了“执行 Access 应用程序所做的事情”和半页关于报告/CSV 提取的注释，但 Access 应用程序甚至没有做我怀疑的事情正确要求。
因此，我必须采用自下而上的方法，并将 Access DB“复制”到 T-SQL，这样我通常会更好地理解需求并采用自上而下的方法，创建新的查询来很好地满足定义的要求。
有没有我可以遵循的方法？我是将其全部展开并花几天时间“摸索”它，还是继续复制 Access 视图并采用渐进式方法来优化查询？
【问题讨论】：
标签： sql sql-server tsql database-design refactoring
了解访问对查询的作用，然后使用这些知识检查您是否已正确传输它。只有完成了这些，你才能考虑重构。我会从慢查询开始，然后从那里开始：找出你需要的索引，然后逐步重写。这样一来，您就可以在证明您成功移动所有内容后立即交付（即使它可能会慢一点）。这比因为问题 X 出现而根本无法交付要好得多。
【讨论】：
我可能会从 Access 数据库开始，就地执行查询并查看结果集是什么。通常，您可以了解查询完成了什么，然后返回您自己的设计来完成它。 （要彻底，无论如何您都需要完全理解其意图。）这听起来像是您将获得的最佳需求陈述 - “就像现在实施一样。”
除此之外，你的方法是我能想到的最好的方法。一旦他们在 SQL Server 中，就开始测试和探索。
【讨论】：
当您处理此类问题时，在进行渐进式更改的同时保持一切正常运行通常会很有帮助。从风险管理的角度来看，这更好。
我会专注于让它工作，然后检查数据库性能和优化性能问题。然后，当您添加功能和修复错误时，清理难以维护的代码。正如您所说，子查询与视图非常相似。因此，如果它没有损坏，您可能不需要更改它。
【讨论】：
这取决于您的时间线。如果您必须让项目尽快运行（我知道这对每个项目都是如此，但如果对您来说确实如此），那么是的，从 Access 复制功能和基础架构，然后在以后进行重构或作为你去吧。
如果你有一些时间可以专注于它，那么现在重构它会给你两件事：
【讨论】：
我建议立即将视图复制到 SQL Server，然后使用其复杂的工具来帮助您了解它们。
例如，SQL Server 可以告诉您哪些视图、存储过程等依赖于特定视图，因此您可以从那里查看该视图是否是其中之一，或者它是否实际用于多个地方。它将帮助您确定哪些视图比哪些视图更重要。
【讨论】：