您可以为开发人员编写针对Oracle的良好SQL提供哪些简单的指导原则?

时间:2009-01-11 23:54:07

标签: sql oracle plsql

我在一组约25名开发人员中工作。我负责提出数据库设计(表格,视图等),并在必要时调用性能调整。

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

您可以为开发人员编写好的SQL提供哪些指导原则?

我的意思是:正确,表现良好,易于理解和维护。

这些只是为了易于遵循指导方针 - 我希望让人们在大多数情况下走上正轨。我们将在有意义的时候打破这些准则。

编辑:我们已经对通过jira工作流强制执行的所有源提交(SQL,java等)进行了代码审查。

10 个答案:

答案 0 :(得分:9)

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

我想提供4条建议

  1. 使用各种ORM,以便您的所有开发人员减少SQL。
  2. 投资培训,购买书籍,派人参加课程。
  3. 由高级SQL开发人员审查所有SQL,所有,我的意思是每个SQL语句,没有例外。通过这种方式,你的资深人员将能够随着时间的推移教小辈们。
  4. 让一个人生活并呼吸Oracle,负责数据库。通过负责,我的意思是了解每一个查询,了解所有结构,并能够提供专家建议。
  5. 您可以在现有指南/清单中添加一些其他内容。

    • 您是否在大型数据集上测试过您的查询?表现如何?
    • 您是否对正在访问的表执行了快速索引审核?是否所有正确的索引?你推荐和新索引吗?
    • 对于大量查询,是否需要任何覆盖索引?
    • 在使用“LEFT JOIN”的情况下,您使用的是“NOT IN”吗?
    • 你的作品在交易上是否合理?你错过了某个地方的交易吗?

答案 1 :(得分:4)

以下是我在指南中已有的内容。

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

我在用我们的数据库架构相关的示例写出的实际指南中略微扩展了这些要点。

答案 2 :(得分:3)

阅读Tom Kyte的书。他解释了如何编写快速代码以及如何衡量性能和可伸缩性。如果您遇到问题,可以在“询问汤姆”网站上找到答案。

答案 3 :(得分:2)

介绍涵盖以下内容的基本风格指南:

  • 命名(所有内容 - 表,列,过程,别名,......)。
  • 格式化风格
    • 线宽
    • 什么保留字需要换行(例如在哪里)
    • 是保留字大写或小型大写
    • 缩进
    • ...

以下是一些例子:

对命名非常严格,您可以更轻松地阅读其他人的代码。
就格式而言,有些工具可以自动格式化,所以也许你不需要在这里详细描述。

答案 4 :(得分:2)

  • 如果您是数据库开发人员,则需要知道执行计划是什么。如果你不这样做煤矿或其他东西。
  • 开发前:
    • 首先,您认为最好的执行计划
    • 第二次您创建表和索引,
    • 第三您使用提示来说服优化程序制定您的计划。
  • 使用提示。忘记自动优化,这是一个营销神话。没有优化器比您更了解您的数据,也永远不会。
  • 没有“创建查询的程序员”和“创建索引的系统管理员”。程序员编程,系统管理员进行备份(或他们做的任何事情)。
  • 触发器是邪恶的。
  • 为列,表格和视图(SELECT prs_name FROM t_person
  • 添加前缀
  • 制作行并缩进

答案 5 :(得分:1)

一些Oracle基础知识的长达一小时的演示(例如解析,SGA与PGA)。 “做这个”规则可能适用于您的情况,也可能不适用。让他们了解数据库方面做了什么,他们至少有一个决策依据。 加上代码评论。

答案 6 :(得分:1)

对的程序。它为敏捷开发提供的任何优势,至少是SQL开发的两倍。

第二选择,所有SQL的代码审查。

答案 7 :(得分:0)

  • 如果可以提供帮助,请不要编写SQL,尽可能使用HQL(或JPQL在Java EE上)
  • 请勿使用SELECT *
  • 明智地选择您的互联网资源(例如asktom.oracle.com
  • 不要使用游标
  • 不要在SQL中进行字符串连接
  • 编写查询以便他们使用索引(从根本上说这意味着对存在的索引建立基础WHERE谓词)
  • 使用MERGE代替其他尴尬的'upsert'类型逻辑
  • 使用日期时,请确保您了解它们在Oracle中的存储方式与它们在Java中的存储方式,尤其是与TimeZone相关时。根据日历/日期类型,可以删除此信息,将其重新映射到默认语言环境的TZ等。
  • 最重要的是:不要以开发人员为借口不知道如何编写好的SQL,以及数据库的工作方式。您不必是DBA,但您需要投资自己的培训,以使自己适合这项任务。出于同样的原因,贵公司也需要对此进行投资。

我并不是说这些“不应该”总是适用。就是这样,如果你在谈论一个对Oracle不熟悉的开发人员,他们需要知道他们在做什么之后才开始决定这些类型的东西是否必要和适当。

答案 8 :(得分:0)

除了建议高级程序员审核查询外,如果您可以获得支持,请进行代码审核,其中涉及尽可能多的团队成员。

答案 9 :(得分:0)

我绝不是一个大师,但这是我的提示:

  • 除非您确实需要一个有序列表,否则不要使用ORDER BY,因为它会导致性能下降。
  • 了解解释计划,并认识到您的开发环境计划通常与您的生产环境不同。不要指望它能准确反映现实生活中的表现
  • 使用提示的优点是你可以选择你的解释计划,使用提示的缺点是最佳计划可能会随着时间而改变,你可能会选择一个长期不是最优的计划
  • 确保开发人员知道何时使用INNER JOIN,OUTER JOIN,[NOT] IN,[NOT] EXISTS - 您可以实施许多流程,但是一个或两个笛卡尔产品会使生产性能下降< / LI>
  • 确保您的开发人员了解索引 - 它们是什么,何时应该使用,何时应该避免使用
  • 让DBA监控最常执行的查询和最昂贵的查询,并将其作为优化候选者进行突出显示
  • 同行评审
  • 编码标准(特别是关于特别长/复杂查询的代码注释)
  • 单元测试