すべてのSQLステートメントはDBAによってレビューされる必要があります—共通ですか？

つまり、スキーマの変更だけではありません。主キーに対する単純なSELECTでさえ、他の開発者によって（コンテキストで）コードレビューされているにもかかわらず、コードから抽出され、EXPLAIN出力で送信されるすべてのステートメントのDBAレビューがなくても、実稼働に入ることはできません。詳細呼び出される頻度など

あなたがそのような環境にいた場合、あなたはそれが純利益であるか、開発の足かせであると思いましたか？リレーショナルデータベースを長年使用してきた人として、「開発者がデータベースを使用することを信頼できない」という態度は不当だと感じており、この状況がどれほど一般的かについては興味があります。価値があるのは、これはWeb開発のためだけであり、重要なことではありません。

私の以前の仕事の1つで、私（他の3人のプログラマーと共に）は、約40人以上のプログラマーの実稼働に入る前に作成または更新されたすべてのストアドプロシージャをレビューする責任がありました。レビュアーとして、それは私の時間の本当のドラッグでしたが、多くの開発者がたまに間違いを犯すので、全体的にそれがまだ必要でした。本当に悪い（効率的な）SQLステートメントを書いたオフショアプログラマーがいて、彼らは完全に学習を拒否した（そのチームは最終的に閉鎖された）からです。

全体的に私たちは探しました：

• インデックスの使用-クエリはテーブル全体をスキャンしていましたか？
• 保守性-何かがハードコードされているため、数週間後にクエリを変更する必要がありましたか？クエリは読み取り可能ですか？
• 全体的な効率-内部結合を既存のものに置き換えることができますか？Withブロックを追加すると役立ちますか？
• ロックの問題-クエリはデータベースをロックし、更新の発生を防ぎますか？これは私が考えている以上に起こりました。

多くの場合、ほとんどのクエリに問題はなく、私たちはそれを推進しました。ただし、各レビューはクエリに応じて10分から2時間かかりました。私の一部は、いくつかのレポートが別のアプリケーションで問題を引き起こしていたため、恐ろしい午前2時の電話を防ぐことができたため、レビューをするというアイデアが気に入りました。しかし同時に、私たちはすべて大人であり、クエリを書いている人はすべて自分でやるべきだから、ちょっとやり過ぎだと思った。

複雑なクエリは標準のコードレビューの一部である必要があると思いますが、DBAを通過する必要はありません。また、単純なinsert / update / deleteステートメントを確認する必要もありません。さらに、クエリの作成者として、いつ複雑になりすぎたのか、いつDBAにレビューを依頼するのかを知っておく必要があります。

更新 私の最初の仕事では、すべてのクエリはDBAによって作成され、それが開発の大きな時間のキラーでした。必要なすべての列、列が配置されたテーブル、最後に検索条件を送信する必要がありました。基本的な挿入/更新/削除ステートメントでさえ、DBAを通過する必要がありました。最終的には、必要なSQLを記述し、それを見て必要な変更を加え、ストアドプロシージャをラップすることができるようになりましたが、そこには数年しかありませんでした。その特定の会社は最近の大学の卒業生をたくさん雇いました、そして、これは新しい人がパフォーマンスを殺したクエリを書かないことを保証した方法でした。

環境、産業、会社に完全に依存しています。

いくつかの例：

• NASAでは、複数レベルのチェックとレビューが標準です。最もよく知られている「二重チェックすべき」は、火星にプローブが送られ、米国はフィート単位で計算しましたが、ヨーロッパ人はメートル単位で計算しました。プローブが失われました。

• DBAのないスタートアップ（最近では一般的）では、DBAのレビューはなく、プログラマのレビューさえありません（たとえば、社内に他のプログラマがいない場合）。

• 製品が数億行のデータウェアハウスである会社では、クエリが効率的かつ正確であることを確認することが、チェックする必要があるビジネスの中核の重要な問題になる可能性があります。

主な製品が主に静的なWebサイトであり、データベースとのやり取りが少ない会社は、データベースとその効率性の関連性が低いと見なす場合があります。会社は、最も重要と見なされる静的ページにレビュー「予算」を費やすことを選択する場合があります。

私はそのような環境で働いたことはありません、私はそれを嫌うだろうと確信しています。これに関するいくつかのメトリックの追跡を開始することを考えます...

• 開発者がSQLをコードから引き出してDBAに送信する準備に費やす時間
• DBAがSQLをレビューするのにどれくらい時間がかかりますか？
• DBAはどのくらいの頻度で変更を要求しますか？クエリ
  タイプ別に分類しますか？

ほんの少しの間これを追跡することは、それがどれほど効果的であるかに対するドラッグの量を示す可能性が高いでしょう。

ほとんどの開発者は、データベースに関しては無知です。彼らは彼らの無知にさえ気づいていません。私はかつては無知な開発者でした。

開発者は、最適化が悪の世界に住んでいます。この考え方は、ディスクに対して操作を実行しているときには機能しません。必要なサイズの8倍のデータ型を選択すると、そのマインドセットは機能しません。これにより、インデックスが必要なサイズの8倍になり、メモリに収まらなくなります。テーブル内のすべての列を冗長に更新する汎用APIに対してプログラミングする場合、その考え方は機能しません（Java Beanには感謝しません）。

彼らは、全表スキャンが何であるかを知りません。彼らは、カーソルを開く代わりに、単一のセット操作でデータを処理する方法を知りません。カーソルよりもさらに悪いのは、データをクエリし、単一の単純なプレーン更新で十分な場合に、行ごとにデータベースを行き来するプロセスです。ひどいパフォーマンスになります。

彼らは、大きなテーブルに対するレポートの深刻な影響を知りません。レポートの必要性には、スタースキーマとそれにデータフィードを作成する必要があるかもしれません。あなたの平均的な開発者は、既存のテーブルをクエリするだけで、クエリの実行に3時間かかる理由を疑問に思うでしょう（これは実際の数字です）。

平均的な開発者が持っている知識は、ユーザーが単にレコードを編集する「平均的な」CRUDアプリに十分です。彼らがRuby-on-Crackバブルから抜け出して現実の世界に入ると、それは十分ではありません。

データベースの大きさ、およびデータベースが複数のアプリケーション間で共有されているかどうかによって異なります。多くの場合、DBAチームは、適切なインデックスが適切に配置されていることを確認できるように、またはテーブルをパーティション分割する必要がある場合に誰に通知するかを確認できるように、実行するクエリを知りたいと考えています。また、クエリ実行プランを読んだり、パフォーマンスを改善するためにヒントを指定できる場所を見つけたりする点で、平均的な開発者よりも少し優れている傾向があります。また、彼らが次のリリースで影響の大きいクエリのいくつかがダウンすることを知らせて、オプティマイザのさまざまな統計を収集できるチャンスでもあります。

私はそのような環境で働いたことがありません。

チームワークと敵対的な官僚主義の間には違いがあります。開発者として、難しいクエリに関するDBAのインプットが欲しいです。しかし、私はいつ助けを求めるかを知っています。

単純なSELECTクエリに対して十分な能力がない場合、解雇されます。

これをいくつかの異なる場所で見ました。理論的には素晴らしいですが、効果があることはめったにありません。その理由は次のとおりです。まず、DBA（または他の人）のチームがいる場合、一般的に、グループの最も能力の低い、または嫌いな人がレビュー作業の矢面に立つことがわかりました。なんで？誰もそれをやりたがらず、他の誰もがおそらくより緊急な他のことをするのに忙しいからです。これまでにDBAが座って、「すべてが完璧に動作している。ただ座ってネットサーフィンをすることができます。何かすることがあればいいのに」と言いました。私も、少なくとも良いものではない。彼らは他の誰よりも忙しく、忙しいです。これは、最も能力の低い人がレビューを行う可能性が最も高いことを意味し、これはまさにあなたがそれをしたくない人です。あなたがレビューしたいコードは、人々が見て、ある種の黒魔術として偽装する本当に難しいコードです。ジュニアDBAまたは単なる悪いDBAは、本当に難しいクエリがどのように機能するかという微妙な点を把握することはできません。「主キーを使用してテーブルから単一の行を選択することは考えていませんでした。DBAはあなたが命の恩人です。」と言う人はほとんどいません。したがって、このシナリオでは、実際に行うことは、ほとんど価値のない多くの作業を作成することです。主キーを使用してテーブルから単一の行を選択することを考えてください！DBAに感謝します。あなたは命の恩人です。」このシナリオでは、あなたが本当にしていることは、ほとんど価値のない多くの仕事を作成することです。主キーを使用してテーブルから単一の行を選択することを考えてください！DBAに感謝します。あなたは命の恩人です。」このシナリオでは、あなたが本当にしていることは、ほとんど価値のない多くの仕事を作成することです。

第二に、DBグループにとっては単なる作業が多いということです。彼らが他のことを見ても、おそらく起こりそうなことは、彼らがそれを簡単に見て、何かが見落とされることです。彼らは忙しい人であり、コードのレビューは本当に時間がかかります。実際のところ、他の人が怠けてアウトとして使用するのは言い訳であり、最終的にはこれが行われるため、彼らがこれを任されることは公平ではありません。本番で何かが壊れ、開発者はすぐに「DBAがそれをレビューしました」と指摘します。今ではこれは常に真実です。しかし、それは真実であり、多くの場合、コードを実際にレビューする必要がある人々からのものです。したがって、DBAを余分な作業で埋めて、その人が他の人の間違いに対して責任を負うように強制しました。

この問題を本当に解決する唯一の方法は、SQLコードの書き方を知っている人に書いてもらうことです。彼らは時々DBAから入力を受け取るべきですか？もちろん、彼らはそうすべきですが、最初に正しくそれをする時間がないなら、いつそれを修正する時間を見つけるのでしょうか？

私はそのような環境で働いてきました。すべてのシステム変更は、適切なピアによってピアレビューされました。私にとっては、数日前に事前に計画を立てて変更を送信する必要がありました。SQLは最終的にSQLを運用環境にリリースするDBAに渡されました。

私のSQLは通常問題ありませんが、いくつかの愚かなエラーをキャッチしました。最初は過度に官僚的な感じがしますが、私は金融の仕事をしています。数ヶ月前、ここにある大手銀行が定期的なアップグレードを台無しにし、すべてのトランザクションを台無しにして何百万人（少なくとも数十万人）の人々が手に入れることができないとき、あなたは何が起こるかを見ました。彼らのお金で。

さらに先に進みます。周囲のコードを確認して、変数がクエリにどのように渡されるかを確認します。多くの場合、基本的な知識が不足しているため、開発者がどのようにアプリケーションをSQLインジェクション攻撃にさらすかを確認します（「これはハッキングできない」という誤った仮定）。

また、経験のない開発者は、ORMの誤用や最適とはほど遠いクエリを使用して、データベースをひざまずかせる可能性があります。

私が働いている最新のプロジェクトでは、フロントエンド開発者は誰も直接データベースにアクセスできません。それらは、与えられたデータのセットを返す関数の需要を高め、バックエンドの開発者はそれらのためにそれを準備します。フロントエンド開発者はUIを記述し、バックエンド開発者が作成した関数が提供するデータを処理します。

開発チームには、使用しているDBMSプラットフォームで経験を積んだ4人のデータベース開発者のサブチームがいます。すべてのSQLを作成するか、少なくともレビューを行い、.Net開発者が作成したSQLのコーディング基準を満たすように変更を加えます。彼らはプロジェクトチームの一員です。実動DBAは完全に異なる部門に属し、その業務は運用中です。彼らは私たちのSQLコードやスキーマをレビューせず、展開さえスクリプト化されています、彼らがするすべてはスクリプトを実行するだけです。最も役立つのは、パフォーマンスのチューニングです。