2

我在一个由大约 25 名开发人员组成的团队中工作。我负责提出数据库设计（表、视图等），并在必要时被称为 apon 以进行性能调整。

有几个不同的应用程序可以连接。数据库访问是通过 JDBC、hibernate 和 iBatis SQL 映射来实现的。具有不同经验水平的开发人员编写 SQL 语句。

您会为开发人员编写好的 SQL 提供哪些指导？

好的我的意思是：正确、执行良好、易于理解和维护。

这些只是为了易于遵循指导方针——我想让人们在大多数情况下走上正确的轨道。我们将在合理时打破这些准则。

编辑：我们对通过 jira 工作流强制执行的所有源提交（SQL、java 等）进行了代码审查。

4

10 回答 10

9

如果您有 25 名开发人员针对您的数据库编写 SQL 查询，那么您将遇到很多麻烦。当您的初级开发人员正在学习 SQL 并检查混乱时，指南并不值得。

我想提供 4 条建议

  1. 使用某种 ORM，这样您的所有开发人员都会编写更少的 SQL。
  2. 投资培训，购买书籍，派人参加课程。
  3. 所有的 SQL 都经过高级 SQL 开发人员的审查，我的意思是每条 SQL 语句，没有例外。这样，随着时间的推移，您的高级人员将能够教初级人员。
  4. 有一个人，他生活和呼吸 Oracle，负责数据库。负责任的意思是知道每个查询，了解所有结构并能够提供专家建议。

以下是您可以添加到现有指南/清单中的一些额外内容。

  • 您是否在大型数据集上测试过您的查询？表现如何？
  • 您是否对正在访问的表进行了快速索引审查？所有正确的索引都到位了吗？你推荐和新的索引？
  • 对于大量查询，是否需要任何覆盖索引？
  • 在应该使用“LEFT JOIN”的情况下，您是否使用“NOT IN”？
  • 你的工作在交易上是合理的吗？您是否错过了某处的交易？
于 2009-01-12T00:09:17.913 回答
4

这是我的指南中已有的内容。

  • 成组工作，而不是逐行
  • 让事情进展得更快的最好方法是避免做你不必做的工作
  • 数据库喜欢加入
  • 完全限定并指定列名（因此在添加其他列时 SQL 不会中断）
  • 只选择你需要的数据（永远不要选择*，永远不要比你需要的行多，永远不要每列都只是因为它在那里）
  • 如何使用 rownum 限制结果集
  • 绑定变量与文字（在所有与倾斜数据相关的特殊情况下使用绑定变量）
  • 避免对 WHERE 子句中的列进行函数或计算（基于函数的索引的特殊情况除外）
  • 对返回多于一行的所有查询使用 ORDER BY（这主要是为了可测试性）

在我用与我们的数据库模式相关的示例编写的实际指南中，这些要点中的每一个都得到了扩展。

于 2009-01-12T02:01:09.157 回答
3

阅读汤姆凯特的书。他解释了如何编写快速代码以及如何衡量性能和可伸缩性。如果您有问题，您可能可以在“ask tom”网站上找到答案。

于 2009-01-12T18:12:38.197 回答
2
  • 如果您是数据库开发人员，您需要知道什么是执行计划。如果您不这样做，那就去煤矿或其他地方。
  • 开发前：
    • 首先，你认为最好的执行计划是什么，
    • 其次，您创建表和索引，并且
    • 第三，您使用提示来说服优化器提出您制定的计划。
  • 你确实使用了提示。忘记自动优化，这是一个营销神话。没有优化器比您更了解您的数据，而且永远不会。
  • 没有“创建查询的程序员”和“创建索引的系统管理员”。程序员编程，系统管理员进行备份（或他们所做的任何事情）。
  • 触发器是邪恶的。
  • 为列、表和视图添加前缀 ( SELECT prs_name FROM t_person)
  • 制作线条和缩进
于 2009-01-15T23:56:26.737 回答
2

介绍基本风格指南，包括：

  • 命名（一切 - 表，列，过程，别名，...）。
  • 格式样式
    • 行宽
    • 哪些保留字需要换行（例如 where）
    • 是保留字大写或小写
    • 缩进
    • ...

这里有些例子：

命名要严格，你会更容易看懂别人的代码。
至于格式化，有一些工具可以自动格式化，所以这里可能不需要很详细的描述。

于 2009-01-12T00:17:29.130 回答
1

Pair-program. Any advantange it provides for agile development in general, at least doubles for SQL development.

Second choice, code reviews for all SQL.

于 2009-01-16T00:12:08.717 回答
1

一个小时的关于 Oracle 基础知识（例如解析、SGA 与 PGA）的演示。“这样做”规则可能适用于您的情况，也可能不适用于您的情况。让他们了解数据库方面的工作，他们至少有一个做出决定的基础。加上代码审查。

于 2009-01-12T01:15:09.920 回答
0

我绝不是大师，但这里是我的提示：

  • 除非您确实需要有序列表，否则不要使用 ORDER BY，因为它会导致性能下降。
  • 了解解释计划，并认识到您的开发环境的计划通常与您的生产环境不同。不要指望它能准确反映现实生活中的表现
  • 使用提示的优点是您可以选择解释计划，使用提示的缺点是最佳计划可能会随着时间而改变，并且您可能会选择长期不理想的计划
  • 确保开发人员知道何时使用 INNER JOIN、OUTER JOIN、[NOT] IN、[NOT] EXISTS - 您可以实施很多流程，但一两个笛卡尔产品会降低生产性能
  • 确保您的开发人员了解索引 - 它们是什么、何时应该使用、何时应该避免使用
  • 让 DBA 监视执行次数最多的查询和最昂贵的查询，并将它们突出显示为优化的候选对象
  • 同行评审
  • 编码标准（尤其是对特别长/复杂查询的代码注释）
  • 单元测试
于 2009-02-23T09:56:13.047 回答
0

除了由高级程序员审查查询的建议外，如果您能获得支持，请让尽可能多的团队成员参与代码审查。

于 2009-01-12T17:11:17.167 回答
0
  • 如果可以，请不要编写 SQL，尽可能使用 HQL（或 JPQL 在 Java EE 上）
  • 不要使用SELECT *
  • 明智地选择您的互联网资源（例如asktom.oracle.com）
  • 不要使用游标
  • 不要在 SQL 中进行字符串连接
  • 编写查询以便它们使用索引（从根本上说，这意味着 WHERE 谓词基于存在的索引）
  • 使用MERGE而不是其他笨拙的“upsert”类型逻辑
  • 处理日期时，请确保您了解它们在 Oracle 中的存储方式与它们在 Java 中的存储方式，尤其是与 TimeZone 相关时。根据日历/日期类型，可以删除此信息，重新映射到默认语言环境的 TZ 等。
  • 最重要的是：不要以作为开发人员不知道如何编写好的 SQL 以及数据库如何工作为借口。您不必成为 DBA，但您需要投资于自己的培训以使自己适合这项任务。同样，您的公司也需要对此进行投资。

我并不是说这些“不要”总是适用。只是，如果您谈论的是对 Oracle 不满意的开发人员，他们需要在开始决定这些类型的事情是否必要和适当之前知道自己在做什么。

于 2009-01-12T00:02:28.863 回答