SQL レビュー: Lint からガバナンスへ

SQL レビューとは、SQL の変更 (スキーママイグレーションやデータ操作) が正しく、安全で、ポリシーに準拠していることを、データベースに対して実行する前に検査する運用です。位置づけは、構文とスタイルを見る SQL Lint と、人がプルリクエストを読むコードレビューの中間にあります。SQL レビューのスコープはどちらよりも狭く、自動化され、データベースを理解し、成熟した実装では変更ワークフローの中に承認ゲートとともに収まります。広いカテゴリーについてはデータベース変更管理とはを参照してください。

SQL レビューの 3 つのレイヤー#

「SQL レビュー」と呼ばれるツールの多くは、これら 3 レイヤーのいずれか 1 つ、2 つ、あるいは全部に位置します。市場のカテゴリ混乱は、Layer 1 のツールと Layer 3 のツールが両方とも「SQL レビューやってますか？」に「やってます」と答えてしまうところから来ています。

Layer 1: Lint#

最も明快な例は SQLFluff です。Linter は SQL の構文の正しさとスタイル規約を確認します — キーワードの大文字小文字、インデント、禁止関数。これは JavaScript における Prettier や ESLint と同じカテゴリの仕事です。便利で、コードレビューでスタイルの口論を避けられますが、SQL が何をするかは分かりません。

Layer 2: セマンティックルール#

Layer 2 はデータベースを理解するルールを足します。主キーの欠落、巨大テーブルを同期的に書き換える ALTER TABLE、WHERE 句のない DELETE、索引のない外部キーカラム — これらは構文エラーではありませんが、本番で痛い目にあいます。この層のルール例:

• すべてのテーブルで主キーを必須にする — 行がアドレス可能になり、レプリケーションも機能する。
• 外部キー制約でのカスケード削除を禁止する — 1 行の DELETE が依存行を黙って一掃する事故を防ぐ。
• NOT VALID の CHECK 制約を強制し、その後に検証ステップを続ける — 部分的に検証された制約を残さない。
• すべての外部キーカラムに索引を必須にする — FK での結合が子テーブル全体をスキャンしないようにする。

SQLFluff はこれらをカバーしません。SonarQube は一握りカバーします。データベースネイティブのレビューツール (Liquibase Quality Checks、Bytebase SQL レビュー、Flyway Teams SQL checks) は数十から数百カバーします。

Layer 3: ポリシーと承認#

Layer 3 は SQL レビューがガバナンスになる層です。SQL がきれいかどうかだけでなく、その人がそれをどの環境にどの承認の下で適用できるかを判断します。dev では警告のルールが prod ではブロックになる。PII 分類のテーブルに触れる変更は、SQL の中身に関わらず DBA のサインオフを必要にする。例外はその理由とともに記録される。静的 Linter はこの層に立ち入りません。

静的 Linter vs レビュープラットフォーム vs DBA レビュー#

「SQL レビューツール」と呼ばれていても、その仕事は一様ではありません。実用上の違いは、レビューがどこで走るか、どのルールを強制できるか、ポリシーが環境ごとに変えられるか、人の承認がレビューの中に同居するかプルリクエストから縫い合わせるか、に現れます。

この表で見た目以上に大事な列が 2 つあります。環境別ポリシーは、ガバナンスが始まる地点です。dev でも prod でも同じルールしか持てない Linter は、何もブロックしないほど緩いか、dev が苦しくなるほど厳しいか、のどちらかをチームに選ばせます。環境別ポリシーがあれば、dev では警告、prod ではブロック、という現場が本当に必要としている挙動になります。

「レビュー内に人の承認」は承認フローがどこに住むかです。多くのスタックでは、承認者は GitHub の PR diff を読み、SQL レビュー結果は CI ログや別コンソールに置かれています。ルールの結果と承認判断が同じ画面に並ぶ UX はそれと大きく異なり、承認者が違反に気づくかどうかを左右します。

Bytebase での SQL レビュー#

Bytebase は同じルールエンジンを 3 つの経路で公開します: GUI の変更 Issue、CI パイプラインのチェック、REST API。ルール、環境別ポリシー、監査証跡は共有です。違いは開発者や接続先ツールが SQL をどこから投入するかです。

変更 Issue (GUI)。 主経路です。開発者が対象データベース向けに Issue を起票し、SQL を貼り付けたりアップロードして提出します。ルールは対象環境のポリシーに対してインラインで走ります — スタイル違反は警告、安全違反はエラー。承認者は同じ Issue を開きます。ルール結果、SQL 自体、環境ポリシー、承認ボタンが同じ画面に並びます。承認者は SQL とそのルール出力を同時にレビューしている — それが設計の狙いです。

具体例: 開発者が ALTER TABLE users DROP COLUMN email を提出します。ルールエンジンは非加算 (破壊的 — 動作中のアプリケーションがまだ参照している可能性) と判定します。Issue は本番環境のポリシーに従って DBA レビュワーへルーティングされます。DBA は Issue を開き、SQL の横に「破壊的変更」の警告を見つけ、デプロイプランを確認し、当該カラムを未だに読んでいるアプリケーションコードを指してコメント付きで却下します。1 つの Issue が SQL、ルール違反、レビュー判断、承認者、監査レコードを保持します。証跡のコンプライアンス側面は SOC 2 のための監査ログを参照してください。

CI / GitOps。 GitOps なデータベースワークフローを採るチームでは、同じルールエンジンが GitHub や GitLab のプルリクエストのチェックとして動きます。違反は PR コメントと CI ステータスとして現れます。GUI 経路とのトレードオフ: 承認者はいまや PR diff を読むコードレビュワーであり、ルール出力は CI ログ、ワンクリック先に置かれます。設定の詳細は GitHub に SQL レビューを統合するに。

REST API。 同じエンジンは REST API でも公開され、言語非依存です。Liquibase や Flyway を埋め込むときのように JVM を走らせる必要がありません。Jenkins のシェルステップ、ServiceNow 駆動の承認、ネイティブ GitHub/GitLab 統合でカバーされない内製ダッシュボードと Bytebase をつなぐ際に、チームはこの経路を選びます。

私たちが一緒に仕事をするチームで Bytebase がスタックに入る理由は、たいていこれです: 彼らの CI はすでに SQLFluff やスキーマチェックを走らせている。それでも本番 DDL に人のサインオフが必要。自動チェックと人の承認はふつう別ツール・別キューに住み、監査証跡は事後に縫い合わされる。これを 1 つのワークフローに統合することが、Bytebase が雇われる差別化要因です。

FAQ#

SQL レビューとは？ SQL レビューとは、SQL の変更をルール集合 (セマンティック、性能、ポリシー) に照らして自動チェックし、データベースに対して実行する前に検査することです。位置づけは SQL Lint (構文とスタイルのみ) とコードレビュー (人が PR を読む) の中間です。成熟した実装では、承認者がルール結果と SQL を並べて見れる人の承認ゲートも含みます。

SonarQube は SQL レビューをするか？ SonarQube はソースレベルのコード品質課題として SQL を Lint します。SQL がどの環境で動くかは知らず、承認でゲートせず、データベース変更ワークフローには立ち入りません。Bytebase や Liquibase Quality Checks のようなデータベース理解付きの SQL レビュープラットフォームとは、別カテゴリのツールです。

SQL レビューはどんなルールを見るか？ 主要な SQL レビューツールのルールカテゴリは、おおむね 5 群に分かれます: 構文とスタイル (大小、禁止関数)、命名 (テーブル/カラムの規約)、安全性 (非加算なスキーマ変更、WHERE のない DELETE)、性能 (索引欠落、非効率な結合、巨大同期 ALTER TABLE)、スキーマ互換性 (破壊的変更、FK 整合性)。ルール数は SQLFluff の約 30 から Bytebase の 200+ まで幅があります。全カテゴリをカバーするツールばかりではありません。

SQL Lint と SQL レビューの違いは？ Lint は Layer 1: 構文、スタイル、フォーマット。SQL レビューはこれに Layer 2 (データベースを理解するセマンティックルール) と Layer 3 (承認ゲート付きの環境別ポリシー) を加えます。Linter は IDE や CLI に住めます。完全な SQL レビューは変更ワークフロー内で走ります — ルール結果が承認判断に影響を与えるからです。

SQL レビューはコードレビューと同じか？ 違います。コードレビューは PR を読んで設計と正しさを評価する人の活動です。SQL レビューは自動のルール強制で、プラットフォーム実装ではそれに人の承認ゲートが加わります。両者は補完的です。コードレビューは SQL の意図を読み、SQL レビューはそれをルールと本番ポリシーに照らして実行前に検査します。