我希望这是一个比“阅读 1000 页的书”答案更短的问题，但是，如果这是真实情况，那就用它来打击我。
我不是真正的 DBA，我是一名意识到我们需要 DBA 的软件开发人员，但我工作的商店的 DBA 为零。然而，我们的 MS SQL 数据库设计包括几个核心存储过程，是一团糟。存储过程很慢，我们怀疑它们有错误，但我们甚至不知道它们应该如何工作，所以我们不知道如何修复它们。
作为开始，我决定我们将记录它应该如何工作，然后我们将开始单元测试，并建立一组单元测试来帮助证明存储过程确实有效。它们执行的逻辑是我们应用程序的关键部分，你可以说，它是我们公司主要产品的“皇冠上的宝石”，它的工作方式完全没有记录。
我正在寻找专业 DBA 可能期望拥有的特定技术文档，或者如果他们必须自己编写，以了解相互调用的存储过程的巨大网络。
记录大型存储过程的常用格式是什么？每个 In 参数的预期值的描述（即“前置条件”、“后置条件”，即对于布尔参数，当您打开或关闭它时会发生什么变化等？）
通常如何记录它？只有 SQL 注释？特定于目的的外部工具？外部“文档”？除了 MS SQL Management Studio，我们没有 SQL 工具，但我们想知道是否有工具可以更好地理解、记录和测试我们的环境。也许这是问我问题的更好方法；我需要什么工具来解决我们的烂摊子？
我们的目标是能够：
A. 使用我们生成的文档或我们添加到环境中的任何工具来帮助理解过程应该如何工作，这样我们就可以继续为存储过程创建单元测试覆盖率。
B. 向客户端应用程序开发人员展示如何正确调用这些复杂的存储过程。
C. 对我们的存储过程进行单元测试。
文档最重要的是它对您有意义。没有真正标准的方法来做到这一点。
如果您有很多存储过程，它们都从一个 Visio 图表开始相互连接，每个过程都有一个对象，那么它们之间的链接以便您可以跟踪从一个过程到另一个过程的事情可能是一个很好的开始。
RedGate SQL Dependency Tracker工具可能会有所帮助。它可以以图形方式向您显示哪些数据库对象（SP/视图/表）相互依赖。我在处理一些我不熟悉的表时使用它来确定禁用约束的顺序。
我还在整个数据库上运行它只是为了好玩，它就是 TMI。如果您能够将其重点放在数据库中不是疯狂相互依赖的特定区域，那么它可能会有所帮助。依赖树具有使用不同算法可视化组织自身的选项，仅此一项就值得进行评估。
追踪。另一种选择是在关键存储过程的开始和结束处写入日志行。每行可以包括一个日期、一个“详细级别”、一个最佳猜测“上下文”、“子上下文”、过程名称。和行数。它可能会一团糟（想想 Windows 事件日志），但在某些部分可能很有用。如果使用 SP 来实际执行日志插入，则可以轻松打开/关闭它而无需太多额外负载 (ymmv)。
旁注，我曾经用很酷的 11 x 17 纸加载打印机，发现了一个漂亮的小字体和一些逻辑缩进，将复杂的数据/SP 流总结为大约 5 页的一些伪 SQL。我很确定我最后只提到了几次，没有人敢靠近它，因为它不是标准的，而且很难相信没有集成的东西，而且可能会过时。文档过程确实迫使人们熟悉代码！