2

私は約 25 人の開発者のグループで働いています。私はデータベースの設計 (テーブル、ビューなど) を考え出す責任があり、必要に応じてパフォーマンス チューニングを依頼されます。

接続するアプリケーションがいくつかあります。データベースへのアクセスは、JDBC、休止状態、および 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 に生き、息を吹き込んでいる 1 人の人物に、データベースの責任を負わせます。責任があるとは、すべてのクエリを理解し、すべての構造を理解し、専門家のアドバイスを提供できることを意味します。

以下は、既存のガイドライン/チェックリストに追加できる追加事項です。

  • 大規模なデータセットでクエリをテストしましたか? パフォーマンスはいかがでしたか？
  • アクセスされているテーブルに対して簡単なインデックス レビューを実行しましたか? すべての適切なインデックスが配置されていますか? 新しいインデックスをお勧めしますか?
  • 大量のクエリの場合、カバリング インデックスは必要ですか?
  • 「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
  • データベース開発者であれば、EXECUTION PLANとは何かを知っておく必要があります。そうでない場合は、石炭か何かを採掘します。
  • 開発前:
    • 最初に、あなたは最高の実行計画が何であるかを考えます。
    • 次に、テーブルとインデックスを作成します。
    • 3 番目に、ヒントを使用してオプティマイザーを説得し、作成した計画を導き出します。
  • ヒントを使用します。自動最適化は忘れてください。それはマーケティングの神話です。オプティマイザーは、あなたよりもあなたのデータをよく知っています。
  • 「クエリを作成するプログラマー」や「インデックスを作成するシステム管理者」はいません。プログラマー プログラム、システム管理者はバックアップ (または彼らが作成するもの) を作成します。
  • トリガーは悪です。
  • 列、テーブル、およびビューにプレフィックスを付けます ( SELECT prs_name FROM t_person)
  • 線を引いてインデントする
于 2009-01-15T23:56:26.737 に答える
2

以下をカバーする基本的なスタイル ガイドを紹介します。

  • ネーミング (すべて - テーブル、列、プロシージャ、エイリアスなど) 。
  • フォーマット スタイル
    • 線幅
    • 改行が必要な予約語 (例: where)
    • 予約語は大文字または小文字です
    • インデント
    • ...

ここではいくつかの例を示します。

命名については非常に厳密にしてください。他の人のコードが読みやすくなります。
フォーマットに関しては、自動的にフォーマットできるツールが用意されているので、ここで詳しく説明する必要はないかもしれません。

于 2009-01-12T00:17:29.130 に答える
1

ペアプログラム。一般にアジャイル開発に提供される利点は、SQL開発では少なくとも2倍になります。

2番目の選択肢は、すべてのSQLのコードレビューです。

于 2009-01-16T00:12:08.717 に答える
1

いくつかの Oracle の基礎 (解析、SGA と PGA など) に関する 1 時間のプレゼンテーション。「これを行う」ルールは、状況に適用される場合と適用されない場合があります。DB側が何をしているのかを理解してもらい、少なくとも決定を下すための根拠を持ってください. プラスコードのレビュー。

于 2009-01-12T01:15:09.920 に答える
0

私は決して達人ではありませんが、ここに私のヒントがあります：

  • 順序付きリストが本当に必要な場合を除き、ORDER BY は使用しないでください。パフォーマンスが低下するためです。
  • 説明計画を理解し、開発環境の計画が本番環境とは異なることが多いことも認識してください。実際のパフォーマンスを正確に反映しているとは思わないでください
  • ヒントを使用することの長所は、説明計画を選択できることです。ヒントを使用することの短所は、最適な計画が時間の経過とともに変化する可能性があり、長期的には次善の計画を選択する可能性があることです。
  • INNER JOIN、OUTER JOIN、[NOT] IN、[NOT] EXISTS をいつ使用するかを開発者が認識していることを確認してください。多くのプロセスを配置できますが、1 つまたは 2 つのデカルト積によって生産パフォーマンスが低下します。
  • 開発者がインデックスを理解していることを確認してください - インデックスとは何か、いつ使用すべきか、いつ使用を避けるべきか
  • DBA に、最も実行されたクエリと最もコストのかかるクエリを監視してもらい、これらを最適化の候補として強調表示します。
  • ピアレビュー
  • コーディング標準 (特に、特に長い/複雑なクエリのコード コメント)
  • 単体テスト
于 2009-02-23T09:56:13.047 に答える
0
  • できる限りSQLを書かないでください。可能な限りHQLを使用してください（またはJPQLはJava EE上にあります）
  • 使用しないでくださいSELECT *
  • インターネット ソースを賢く選択する (例: asktom.oracle.com)
  • カーソルを使用しない
  • SQL で文字列連結を行わない
  • インデックスを使用するようにクエリを記述します (基本的に、これは存在するインデックスに基づく WHERE 述語を意味します)。
  • MERGE他の厄介な「アップサート」タイプのロジックの代わりに使用する
  • 日付を扱うときは、特に TimeZone に関連する場合は、日付が Oracle に格納される方法と Java に格納される方法を理解していることを確認してください。Calendar/Date の種類によっては、この情報を削除したり、デフォルト ロケールの TZ に再マップしたりできます。
  • 最も重要なことは、良い SQL の書き方やデータベースの仕組みを知らない開発者であるという言い訳をしないことです。DBA である必要はありませんが、このタスクに適したものにするために、独自のトレーニングに投資する必要があります。同様に、あなたの会社もそれに投資する必要があります。

これらの「してはいけないこと」が常に当てはまると言っているわけではありません。Oracle に慣れていない開発者について話しているのであれば、それらの種類のことが必要かつ適切であるかどうかを判断する前に、自分が何をしているかを知る必要があります。

于 2009-01-12T00:02:28.863 に答える
0

上級プログラマーにクエリをレビューしてもらうという推奨事項に加えて、賛同を得られる場合は、できるだけ多くのチーム メンバーが参加するコード レビューを行ってください。

于 2009-01-12T17:11:17.167 に答える