每个SQL语句都必须由DBA审查-常见吗？

我的意思是一切，而不仅仅是架构更改。即使对主键进行简单的SELECT也无法投入生产，即使它已经由其他开发人员进行了代码审查（在上下文中），也没有DBA审查每条语句，从代码中提取出来并与EXPLAIN输出一起提交，详细信息它多久被调用一次，等等，等等。

如果您曾经在这样的环境中工作，您是否发现它是净收益或拖累了开发？作为从事关系数据库工作多年的人，我发现“开发人员不能被信任使用数据库”的态度毫无根据，我很好奇这种情况的普遍性。对于它的价值，这仅是用于Web开发，不是关键。

在我以前的工作之一中，我（以及其他三位程序员）负责检查每个创建或更新的存储过程，然后再为大约40个以上的程序员投入生产。作为一名审阅者，这确实拖累了我的时间，但总的来说还是需要这样做的，因为许多开发人员有时会犯一个错误。之所以出现这种情况，是因为我们有一些离岸程序员编写了非常糟糕的（高效的）SQL语句，而他们全力以赴地拒绝学习（该团队最终被关闭了）。

总的来说，我们寻找：

• 索引用法-查询是否在进行全表扫描？
• 可维护性-由于某些内容被硬编码，是否需要在几周内更改查询？而且查询可读吗？
• 整体效率-内部联接是否可以替换为存在的联接？添加With阻止帮助吗？
• 锁定问题-查询会锁定数据库并阻止更新发生吗？这件事超出了我的考虑范围。

大多数查询通常没有问题，因此我们一直坚持下去。但是每次查询要花10分钟到两个小时，具体取决于查询。我的一部分喜欢进行审核的想法，因为它阻止了可怕的凌晨2点电话，因为某些报告导致另一个应用程序出现问题。但是与此同时，我认为这有点过头了，因为我们都是成年人，编写查询的人应该自己做所有这些事情。

我认为复杂的查询应该成为标准代码审查的一部分，但不需要通过DBA。也不需要查看简单的插入/更新/删除语句。另外，作为查询的编写者，您应该知道何时变得过于复杂，并且知道何时要求DBA进行审核。

更新 在我的第一份工作中，所有查询都是由DBA编写的，这是开发时的主要杀手。我必须提交所有想要的列，列所在的表格以及最终的搜索条件。甚至基本的插入/更新/删除语句都需要通过DBA。最终，我可以编写所需的SQL，让他们研究一下并进行必要的更改，然后在其周围包装存储过程，但是那只不过是几年了。那个特定的公司雇用了许多最近的大学毕业生，这就是他们确保新员工不会写导致性能下降的查询的方式。

这完全取决于环境，行业和公司。

一些例子：

• 在NASA，标准的检查和审阅是多层次的。最著名的“应该仔细检查”是当探测器被发送到火星，美国以英尺为单位进行计算，而欧洲人以米为单位进行计算。探针丢失了。

• 在没有DBA的创业公司（如今很常见）中，将没有DBA审查，甚至可能没有程序员审查（例如，如果公司中没有其他程序员）。

• 在一家产品为数亿行的数据仓库的公司中，确保查询的效率和正确性可能是应该检查的业务核心问题。

如果一家公司的主要产品是一个主要的静态网站，并且与数据库的交互较少，则该公司可能会认为数据库及其效率不太相关。可能是公司选择将其审核“预算”花费在最关键的静态页面上。

我从来没有在这样的环境中工作过，我敢肯定我会讨厌它。我想到一个想法来开始跟踪与此相关的一些指标...

• 开发人员花了多少时间将sql从代码中拉出并准备将其提交给DBA
• DBA需要多长时间检查一次SQL？
• DBA多久请求一次更改？按查询
  类型细分？

暂时跟踪一下它可能会显示出它有多大的阻力与它的有效程度。

对于数据库，大多数开发人员一无所知。他们甚至都不知道自己的无知。我曾经是一个无知的开发人员。

开发人员生活在优化是邪恶的世界中。当您对磁盘执行操作时，这种思维方式不起作用。当您选择的数据类型必须比其大8倍时，这种思维定势就无法工作，这会导致索引比其必须大8倍，因此它不再适合内存。当您使用通用API冗余地更新表中的所有列进行编程时，这种思维方式就行不通了（不用了Java Bean）。

他们不知道什么是全表扫描。他们不知道如何在单个设置操作中处理数据，而不是打开游标。比游标更糟糕的是，它们将查询数据，然后在单个简单的纯jane更新就足够的情况下，将数据逐行处理到数据库。导致糟糕的性能。

他们不知道针对大表进行报告的严重影响。可能需要报告将需要创建星型模式并向其中添加数据。您的普通开发人员将只查询exisitng表，并且想知道为什么查询要花3个小时才能运行（这是一个真实的数字）。

您的普通开发人员所掌握的知识足以满足“平均” CRUD应用程序的需要，用户只需在其中编辑记录即可。一旦他们摆脱了Ruby-on-Crack泡沫并进入现实世界，这还不够。

取决于数据库的大小以及它是否在多个应用程序之间共享。DBA团队通常喜欢知道将要运行哪些查询，以便他们可以确保适当的索引在位，或者他们知道如果必须对表进行分区时可以通知谁。在阅读查询执行计划和发现可以指定提示以提高性能的地方时，它们的确比一般开发人员要好一些。对于他们来说，这也是一个提神的机会，因为在下一个版本中一些高影响力的查询将要减少，因此他们可以为优化器收集不同的统计信息。

我没有在这样的环境中工作，我也不会。

团队合作和敌对的官僚主义之间是有区别的。作为开发人员，我很乐意让DBA在棘手的查询中提供意见。但是我知道什么时候寻求帮助。

如果我没有能力胜任简单的SELECT查询，应该被解雇。

我已经在几个不同的地方看到了这一点。从理论上讲很棒，但是我很少看到它有效。这就是为什么。首先，如果您有一个DBA团队（或其他人员），我通常会发现该组中最不称职或最不喜欢的人会受到审查工作的冲击。为什么你说？这是因为，没有其他人愿意这样做，而其他所有人都在忙着做其他可能更紧急的事情。曾经见过DBA围坐在那里说：“伙计们一切运转良好；我可以坐下来上网冲浪。我希望我能做些事。” 我也是，至少不是好人。他们比其他人都忙或忙。这意味着能力最弱的人最有可能进行审阅，而这正是您不想执行的审阅。您要检查的代码是人们真正看到的非常难的代码，并将其作为某种黑魔法散发出去。初级DBA或普通的DBA将永远无法掌握真正困难的查询是如何工作的。很少有人从来没有说过，“伙计，我没想到要使用主键从表中选择一行！谢谢DBA是您的救星。” 因此，在这种情况下，实际上您要做的就是创建很多工作，而价值却很少。不要想到使用主键从表中选择一行！感谢DBA，您是一位救命稻草的人。”因此，在这种情况下，实际上您要做的就是创建很多工作，却几乎没有价值。不要想到使用主键从表中选择一行！感谢DBA，您是一位救命稻草的人。”因此，在这种情况下，实际上您要做的就是创建很多工作，却几乎没有价值。

其次，对于数据库组来说，这只是简单的工作。即使他们确实看了其他事情，也可能会发生的事情是，他们将快速浏览一下，而某些事情将会被遗漏。他们很忙，检查代码确实很耗时。实际上，让他们承担这个任务是不公平的，因为这是每个人都懒惰并将其用作淘汰的借口，这最终会发生这种情况。生产中断了，开发人员迅速指出：“ DBA对此进行了审查。” 现在一直都是这样，不是，但是在一部分时间里这是真的，而且经常是需要真正审查其代码的人员所为。因此，您使DBA付出了额外的工作，并迫使该人应对别人的错误负责，而该人可能不会这样做。

真正解决问题的唯一方法是让知道如何编写SQL代码的人来编写它。他们是否应该不时从DBA获得输入？他们当然应该，但是我一直发现，如果您没有时间在第一时间做正确的事，那么您什么时候才能找到时间来解决它。

我曾在这种环境中工作过。所有系统更改均由适当的同行进行同行审查。对我来说，这仅意味着我必须提前计划并提前几天提交更改。SQL交给了DBA，DBA最终将SQL投入生产。

我的SQL通常没问题，它们捕获了一些愚蠢的错误。刚开始时感觉太官僚了，但我从事金融工作。您看到了几个月前发生的事情（如果您在英国），当时这里的一家大型银行搞砸了例行升级，搞砸了所有交易，导致数百万（至少成千上万）人无法获得用他们的钱。

我什至会走得更远。我将检查周围的代码，看看变量如何传递给查询。通常会因为缺乏基本知识（“这不能被破解”的错误假设）而导致开发人员如何将其应用程序暴露于sql注入攻击。

此外，经验不足的开发人员可能会由于滥用ORM或远非最佳的查询而拖累数据库。

在我从事的最新项目中，不允许任何前端开发人员直接访问数据库。他们对返回给定数据集的函数提出了要求，后端开发人员为它们准备了数据。它运行良好，前端开发人员编写UI，并处理由后端开发人员编写的功能提供的数据。

在我们的开发团队中，有一个由4个在我们使用的DBMS平台上经验丰富的数据库开发人员组成的小组。他们编写所有SQL或至少进行审阅，并进行更改以符合.Net开发人员编写的任何SQL以满足其编码标准。他们是项目团队的一部分。生产DBA属于完全不同的部门，他们的工作是可操作的。他们不会查看我们的SQL代码或架构，甚至没有部署脚本，他们只是运行脚本。他们最大的帮助是性能调整。