我最近开始在一家新公司担任报告分析师。我们没有关于我们的生产报告的文档（参见示例http://snipt.org/AnL），编写大部分报告的人对任何建议都怀有敌意。我有软件开发经验，部门经理让我为我们的 SQL 提出一些标准，所以我正在向 StackOverFlow 社区征求意见。
我认为我们需要为每份报告提供一个叙述，准确说明报告应该提供哪些信息，以及它将如何有助于管理流程。这需要一些我们也没有的流程文档（例如计费流程的工作方式）。我认为在数据库查询策略不明显的情况下，我们需要一个语句来解释查询用于检索数据的策略。最后，我们应该有足够的资源将报告交给新员工，他们拥有运行、维护和修改报告所需的一切。
然后是 SQL 编码标准的问题——注释标题应该包括什么（作者、日期、更改历史......？），以及结构化缩进以提高清晰度。我们是否应该对这些事情进行变更控制，包括代码审查和记录测试？
与其使用标头，不如对您的数据库架构和所有存储过程、视图、udf 等进行源代码控制？
这样您就不必手动维护元数据，随着时间的推移，元数据将不可避免地失去完整性，因为人们忘记更新它。
http://msdn.microsoft.com/en-us/library/ms173550(v=sql.105).aspx
我仔细查看了您通过的查询，我只能说“哇！”。你肯定有你的工作为你完成。
像这样几乎没有注释的过程、嵌入在代码中的常量、全部大写以及子选择的子选择都是噩梦般的维护。我想说写这篇文章的人在那里得到了一些严肃的工作保障。
您关于标题块的建议很好。我喜欢有这些元素：名字；原作者；原始日期；目的; 预期输入；预期产出；以及完整的变更历史，包括：作者；改变日期; 改变的目的。
绝对应该对这些进行版本控制。随着现代源代码控制系统的出现，这应该不是问题。
其他必须做的事情是需要时的描述性注释和代码缩进。有很多优秀的编辑器会自动缩进，所以没有不这样做的好借口。
您提到代码审查和记录测试。这些也是很好的做法，但要使它们有效，您需要有一个愿意接受建设性批评的员工。
感谢您积极主动。我感觉你要从这里上坡！
存在软件可以解决您的问题（例如 TFS）的情况并不罕见，但由于某种原因，您无法在您的环境中使用它。有一些方法可以滥用源代码控制软件——比如流氓开发人员开始在“他的”沙箱之外运行所有报告。而且，版本控制软件并不能解决您的所有问题。例如，它与代码中的注释或命名约定无关。
以下是一些帮助数据库软件维护的“标准”：
当不允许使用版本控制软件时，我有一个描述更改历史的注释块。看起来像：
/*
* GSL 2013-06-08 Modified foo at Jean's request
* GSL 2013-06-01 Created
*/
这适用于视图、存储过程和用户定义的函数。如果我注意到没有评论的更改，那么我会使用“在电子邮件中或当面尴尬”的方法来哄骗坚持。
以下与版本控制无关。
命名约定：不同表中的相同事物始终具有相同的名称。甚至主键。一般来说，我以复数形式命名一个表，然后删除“s”并添加“id”作为主键。
列约定：几乎所有表都有一个主键（表名的单数形式，附加“id”）CreatedAt和CreatedBy列。后者回答了这个问题：“最后一件事是什么？” 和“谁不知道？”
列前缀：对于源列来自数据库外部的表，我使用前缀来指示它们来自何处。类似于jl_telephonenumberJane 列表中某物的电话号码。
捕获错误：我将存储过程包装在try/catch块中并尝试在本地处理错误。通常，存储过程采用 astatus和ErrMsg输出变量，因此我可以将状态信息传回给调用者。而且，调用者总是检查状态。
缩进：这是宗教，我有我的宗教。用一种非常特殊的缩进风格写一本书有一定的优势，这就是我使用的那种。我有足够的经验知道不能把一种特定的风格强加给每个人。但是，代码必须清晰，并且必须能够清楚地区分子查询块。
表别名： Eschew a, b, c, x, y, z. 别名应该是相关表格的缩写。
最后（目前），如果你真的想保证代码的准确性，那么你应该进行代码审查。这将是每周一次 60 分钟左右的会议，将通过一份报告并讨论报告的编码方面。通过指出现有报告中的缺陷，此类审查极有可能证明是非常有价值的。