1. 首页
  2. 问答
  3. 你会给开发人员编写针对Oracle的良好SQL的简单指导原则吗？

你会给开发人员编写针对Oracle的良好SQL的简单指导原则吗？

2009-01-11 24 views
2

我在一群约25位开发人员中工作。我有责任提出数据库设计（表格，视图等），并在必要时被称为性能调优。你会给开发人员编写针对Oracle的良好SQL的简单指导原则吗？

有几个不同的应用程序连接。数据库访问通过JDBC，hibernate和iBatis SQL映射。具有不同级别经验的开发人员编写SQL语句。

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

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

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

编辑：我们已对所有通过jira工作流执行的源提交（SQL，Java等）进行代码审查。

来源

2009-01-11 WW.

+1

你负责数据库的设计和问这个的题？！ – cletus 2009-01-11 23:56:10

+2

是的:)我已经有了指导方针，但我不知道所有事情，我正在寻求改善这种情况。 – 2009-01-12 01:52:10

回答

0
  • 不要写SQL如果你能帮助它，使用HQL（或JPQL是关于Java EE）尽可能
  • 不要使用SELECT *
  • 选择你的互联网资源明智地（例如，asktom.oracle.com）
  • 不使用游标
  • 使得它们使用索引不要做字符串连接在SQL
  • 编写查询（从根本上，这意味着基地WHERE上存在的索引谓词）
    • 而不是其他的尴尬 “UPSERT”类型的逻辑
  • 使用MERGE
  • 当使用日期，请确保您了解他们是如何存储在Oracle与它们是如何存储在Java中，特别是当它涉及到的时区。根据日历/日期类型，这些信息可以被剥离出来，重新映射到默认语言环境的TZ等
  • 更重要的是：不要使用的是一个开发人员不知道如何写出好的SQL借口以及数据库如何工作。您不必是DBA，但您需要投资自己的培训以使自己适合这项任务。同样的道理，贵公司也需要投资。

我不是故意说这些“不应该”总是适用。这只是说，如果你在谈论一个开发谁不舒服与Oracle，他们需要知道，他们开始决定这些类型的东西是否必要和适当之前，他们在做什么。

来源

2009-01-12 00:02:28

+0

其实Oracle游标并不是那么邪恶。它们是做许多事情的标准方式，与SQL Server相比，它是超高效的。 – Cervo 2009-01-12 02:15:17

+0

我不同意这些2： *如果可以帮助，请不要编写SQL Oracle将非常高效地运行SQL，因此在其外部进行操作以获取正确的数据是额外的工作，总是会更慢，难以调试。 *不要使用游标 PL/SQL游标速度很快并且可以完成任务。 – 2009-01-16 12:45:53

+0

我同意不同意不写SQL。即使ANSI SQL也是浪费。为了获得Oracle，你牺牲了第一个出生的孩子，所以你不妨使用Oracle内置的所有漂亮的SQL扩展。在投入了大量资金之后，您可以充分利用它...... – Cervo 2009-01-17 12:54:02

9

如果你有25个开发人员编写的SQL查询你的数据库你是在相当多的麻烦。当您的初级开发人员正在学习SQL并检查混乱时，指南并不值得。

我想提供4项建议

  1. 使用各种各样的ORM让你所有的开发者少写SQL。
  2. 投资于培训，购买书籍，送人上课程。
  3. 拥有所有由高级SQL开发人员审查过的SQL，我的意思是每个SQL语句都没有例外。这样，你的资深人员就可以随着时间的推移向后辈传授知识。
  4. 让一个人生活并呼吸Oracle，负责数据库。通过负责任我的意思是知道每一个查询，了解所有的结构，并能够提供专家意见。

这里有一些额外的东西，你可能会添加到您现有的指导方针/清单。

  • 您是否在大型数据集上测试过您的查询？表现如何？
  • 您是否对正在访问的表执行了快速索引检查？是否有正确的索引？你建议和新的索引？
  • 对于高容量查询，是否需要覆盖索引？
  • 在使用“LEFT JOIN”的情况下，您是否使用“NOT IN”？
  • 你的工作是否有声音？你是否错过了某个地方的交易？

来源

2009-01-12 00:09:17

+0

我们在使用ORM的地方有意义。有时候这不是正确的工具。我们所有的SQL都经历了通常的代码审查过程，我希望能够在拒绝时指向准则。我认为我们不需要麻烦 - 他们编写的代码很好，他们为什么不能很好地编写SQL？ – 2009-01-12 02:02:52

2

介绍基本的风格指南，涵盖：

  • 命名（一切 - 表，列，过程，别名...）。
  • 格式样式
    • 线宽
    • 什么保留字需要新的生产线（例如在）
    • 保留字大写或小写形式
    • 缩进
    • ...

以下是一些示例：

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

来源

2009-01-12 00:17:29 zendar

1

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

来源

2009-01-12 01:15:09

4

以下是我的准则中已有的内容。在套

  • 工作，而不是按行
  • ，最好的办法排，使一些走快是为了避免做工作，你不必做
  • 数据库有爱人士加入
  • 完全有资格和指定列名（所以SQL不破时添加的附加列）
  • 只选择你需要的数据（从未选择*，从来没有更多的行比你需要，永远不会每列只是becaues它的存在）
  • 如何使用ROWNUM限制结果tsets
  • 绑定变量VS文本（在所有使用绑定变量，而是与偏斜数据的几种特殊情况）在WHERE子句中的列
  • 避免功能或计算（除了基于函数索引的一种特殊情况）
  • 使用ORDER BY返回多行所有查询（这主要是可测性）

每个点的扩展位中我已经写了有关我们的数据库模式的一个例子，实际的指导方针。

来源

2009-01-12 02:01:09

0

除了高级程序员对查询进行审查的建议之外，如果您可以获得买入，则需要有尽可能多的团队成员参与的代码审查。

来源

2009-01-12 17:11:17 DCookie

3

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

来源

2009-01-12 18:12:38 tuinstoel

2
  • 如果你是一个数据库开发人员，你需要知道的执行计划是什么。如果你不这样做，我的煤炭或什么的。
  • 开发前：
    • 第一，你认为什么最执行计划会，
    • 第二创建表和索引，以及
    • 您使用提示来说服第三优化器会提出您制定的计划。
  • 你做使用提示。忘记自动优化，这是一个营销神话。没有优化器比您更了解您的数据，永远不会。
  • 没有“创建查询的程序员”和“创建索引的系统管理员”。程序员程序，系统管理员进行备份（或他们所做的任何事情）。
  • 触发器是邪恶的。
  • 前缀你列，表和视图（SELECT prs_name FROM t_person）
  • 让行和缩进

来源

2009-01-15 23:56:26 Quassnoi

1

配对程序。一般来说，它为敏捷开发提供了任何优势，至少使SQL开发翻倍。

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

来源

2009-01-16 00:12:08 dkretz

0

我决不是一个大师，但这里有我的秘诀：

  • 不要使用ORDER BY，因为它会带来性能的下降，除非你真的需要一个有序列表。
  • 了解解释计划并认识到您的开发环境计划通常与您的生产环境不同。不要期望它能够准确反映真实的生活表现
  • 使用提示的优点是你可以选择你的解释计划，使用提示的缺点是最佳计划可能会随着时间而改变，你可能会选择一个计划这是长期不理想的
  • 确保开发人员知道何时使用INNER JOIN，OUTER JOIN，[NOT] IN，[NOT] EXISTS - 您可以放置​​很多流程，但是一个或两个笛卡尔产品将会使生产性能瘫痪
  • 确保您的开发人员了解索引 - 它们是什么，什么时候应该使用，何时应该避免使用
  • 让DBA监控最多执行的查询和最昂贵的查询里斯和强调这些作为优化
  • 同行评议
  • 编码标准的候选人（尤其是代码的注释上特别长/复杂的查询）
  • 单元测试

来源

2009-02-23 09:56:13 darreljnz

相关问题

 相关问题