SQL は 1987 年から標準化されており、次のように維持されています ISO/IEC 9075ただし、すべてのエンジンはその上に独自の方言を追加します。これがまさに、フォーマッタがパターンマッチではなく解析する必要がある理由です。
私が今までレビューしなければならなかった最悪の質問は、1 つの論理的思考で 340 行でした。つまり、1 つとして書かれた Laravel SaaS の収益レポートです。 DB::select() 生の文字列は、3 人の開発者によって 8 か月以上にわたって構築され、それぞれ大文字の使用について異なる考えを持っていましたが、改行については何も考えていませんでした。 テキストの壁のどこかで、 LEFT JOIN 静かに INNER JOIN リファクタリング中に、注文がゼロの顧客はレポートから消えました バグは1 つの単語でした 発見には1 日半かかりました - ロジックが難しかったからではなく、クエリが難しかったからです 読めない、読み取れないコードは、バグを目に見える場所に隠します。
SQL についてのことは、データベースはあなたのフォーマットを気にしません。 パーサーは次のように読みます select id,name from users where active=1 あんど SELECT id, name FROM users WHERE active = 1 同じステートメントとして、同じ実行計画を作成し、同じ行を同時に返します。 SQL のフォーマットは純粋に人間向けです。これがまさにそれを行う価値のある理由です。なぜなら、SQL をレビューし、午前 2 時にデバッグし、後で 3 つのジョブを継承するのは人間だからです。 can't スキム クエリは、can't 検証できるクエリです。
あい SQL フォーマッタ ログから貼り付けられたクエリ、orm's デバッグ出力、coworker's Slack メッセージ、従来のストアド プロシージャを、ワンクリックで一貫してインデントされ、一貫してケースに入れられ、レビュー可能な SQL に変換します。 Toolz.dev 上のクエリは完全にブラウザで実行され、これは他のほぼすべてのテキストよりも SQL にとって重要です。 you'd オンライン ツールに貼り付けます。これは、実稼働クエリにはスキーマが含まれ、場合によってはデータが含まれるためです。
このガイドでは、使い方、実際に重要な書式設定規則 (キーワードの大文字小文字、インデント、および永遠のコンマ戦争)、フォーマッタが毎日元が取れるワークフローについて説明します。
tl;dr: クエリをすべてに貼り付けます Toolz.dev SQL フォーマッタ そして一貫してインデントされた、キーワードケースのSQL - インスタント、フリー、クライアントサイド、サインアップなしを取り戻します フォーマットによってクエリの動作や実行速度が変わることはありません; 人間がクエリを検証できるかどうかが変わります 採用する価値のある規約: 大文字のキーワード、1 行に1 つの節、各節の下のインデント、カンマスタイルを選択して議論するのをやめてください JSON フォーマッタ データベースの上にある API レイヤーと、 テキスト差分ツール クエリの 2 つのバージョンを比較するため。
主な機能
ワンクリックで一貫したインデント
The formatter's core move: each major clause - SELECT、 FROM、 WHERE、 GROUP BY、 ORDER BY ー は、その下に列、条件、結合をインデントして、独自の行を開始します。 " river" structure experienced SQL readers scan by: the eye runs down the left edge reading clause keywords, then dives into whichever clause matters.これは、 " river" structure experienced SQL readers scan by: 目は、左端の読み取り句キーワードを実行し、次に、どの句が重要かを明確に構造レビューする60 行フォーマットされたクエリです もっと早く 6 行のフォーマットされていないものよりも、構造が半分読み上げているからです。私の 340 行のホラー ストーリーは、この形状の 20 分間のレビューになるでしょう。変更された結合タイプは、明らかに間違って、独自の行に一人で座っていたでしょう。
キーワード ケースの正規化
SELECT 対 select genually does't matter to any database - SQLキーワードは標準に従って大文字と小文字を区別せず、どの方言もそれを尊重している。 ただし、混合ケーシングは構造的に同一のクエリが異なるように見える視覚的なノイズであるため、コードベースにとっては非常に重要です。大文字のキーワードは古い規則であり、構文強調表示のないエディターから遡ります SELECT 大文字で でした ハイライト表示。私はまだ大文字を書いています。キーワードは小文字の識別子に対してポップアップ表示され、ログ、差分、平文電子メール、端末出力など、ハイライトを削除するすべてのコンテキストに残ります。フォーマッタは選択した規則に正規化されるため、5 人によって書かれたコードベースは 1 人によって書かれたものとして読み取られます。
ORM とログ出力を処理します
フォーマットが最も必要なクエリは、人間が書いたものではありません。Eloquent と ActiveRecord の出力、ドクトリンの生成結合、クエリの遅いログの単一行のモンスターです。 ORM 出力は、機械生成エイリアス (t0、 t1、 laravel_reserved_0)、そしてそれを生で読むことはあなたが頭痛を得る方法です。 私の唯一の最も頻繁なフォーマッタの使用: Laravel& #39; sクエリログまたはテレスコープからクエリをつかみ、フォーマットし、実際にORMが何をすることにしたのかを見てください - これはすべての"の最初のステップです; なぜこのエンドポイントは遅いです" 調査、直前に EXPLAIN。
多方言の公差
実世界の SQL は、方言のファミリーです。MySQL のバックティック クォート付き識別子、PostgreSQL の二重引用符、 :: キャスト、SQL Server の角かっこ TOP、SQLite はすべての気楽なところです。 便利なフォーマッタは、「ディレクツー」を「修正」するのではなく、方言固有の構文を保持して、最初に方言を宣言するよう要求することなく、それらすべてを処理します。 ANSI/ISO SQL 規格 (ISO/IEC 9075) は共通コアを定義しますが、実際には誰も純粋な標準 SQL を記述しておらず、標準を話すフォーマッタは最初のバックティックで窒息します。
セマンティクスを保持し、保証されています
it& #39; s の恐怖が人々を停止するので、明示的に述べる価値があります: フォーマットは結果を変更できません。 SQL では空白とキーワードの大文字と小文字は意味論的ではありません。歴史的な注意点は、これです 文字列リテラル 照合によって大文字と小文字が区別されるか、または照合に応じて比較されず、フォーマッタが引用された文字列の内側に触れることはありません。 出力は同じステートメントで、バイト単位のバイト数です。 EXPLAIN 両方のバージョンで見たい場合: 同じ計画。
クライアント側、実際にはここが重要です
SQLは、オンラインツールに日常的に貼り付けられる最も機密性の高いテキストカテゴリです。 クエリはスキーマを明らかにします - テーブル名、列名、関係 - そしてログからコピーされたクエリは頻繁にリテラル値を含みます: 電子メールイン WHERE 句、ID 範囲、場合によっては、クエリ文字列にはまったく含まれるべきではないもの。 ザ・ Toolz.dev フォーマッタ ブラウザですべてを処理します; 何も送信されません。 SQL については、特に、I' d はクライアント側の処理を機能ではなく要件と呼びます - ネットワーク タブで検証してから緩和します。
SQL フォーマッタの使い方
ステップ 1: クエリをキャプチャする
SQL をソースからコピーします: 移行ファイル、ストアド プロシージャ、ORM のデバッグ出力 (DB::listen() または、ララベルの望遠鏡、 ActiveRecord::Base.logger Rails)、または APM ツールのクエリ タブの遅いクエリ ログ。 ログからのものである場合、引用符またはパラメーターのプレースホルダー (?、 $1) - that'は問題ありません。フォーマッタはプレースホルダを処理し、それらをはっきりと見ることが重要な場合が多いです。
ステップ 2: 貼り付けとフォーマット
を開きます SQL フォーマッタ、貼り付け、およびフォーマットされたバージョンが表示されます。 dialect 式なし、良いデフォルトを取得するための設定不要。クエリにセミコロンで区切られた複数のステートメントが含まれている場合、それらは個別のステートメントとしてフォーマットされます。移行スクリプトを全体的に読むのに役立ちます。
ステップ 3: レビュアーのように読む
フォーマットが存在することを実行します: 左端をスキャンします。 どのテーブルが結合され、どの結合タイプに結合されますか? は WHERE 節には期待する条件があり、それは次のとおりです AND/OR グループ化はあなたのやり方で括弧を付けました 考えます 彼らはグループですか？ (SQL PUT のオペレータの優先順位 AND 前に OR、、2 つのうち括弧を付けていないミックスは、間違った結合タイプに続いて、レビューで 2 番目に大きなバグ ソースです。) フォーマットされた SQL は、両方の間違いを数秒で表示します。
ステップ 4: コピーして元に戻す - 選択的に
コードベースに向かうクエリの場合は、フォーマットされたバージョンを移行にコピーします。 ->select() 生の表現、 .sql ファイル。 1 回限りのデバッグの場合は、ラウンドトリップを気にしないでください。フォーマットされたコピーは、読んだ瞬間に目的を果たしました。 一か所 でないよ フォーマットされた SQL を貼り付けるには: クエリを構成文字列として保存するシステムに戻します。ここで、誰かの差分ツールが空白の変更の壁を表示します。 常に読み取るための形式。保存されたクエリを再フォーマットして、差分を所有する準備ができている場合にのみ保存します。
ステップ 5: チーム コンベンションを標準化する
The formatter's biggest value is compounding: pick the conventions you can automate - keyword case and indentation width are the two this formatter controls directly - format everything new on the way into the codebase, and SQL review friction drops permanently.フォーマッタ& #39; sの最大の価値は複合化:あなたが自動化できる規約を選ぶ - キーワードケースとインデント幅は、このフォーマッタが直接制御する2 つです - コードベースに入る途中で新しいものをすべてフォーマットし、SQLレビューの摩擦が永久に低下する選択を寄稿ガイドに書き留めます。 選択された特定の規約は、同じものを使用しているすべての人よりもはるかに重要ではありません - この文は、ソフトウェアのすべてのフォーマット議論に当てはまり、議論の最中にほぼ誰も信じていません。
テクニカル ディープ ダイブ: 意見を持つ価値のある慣習
キーワードのケーシング。 大文字のキーワード、小文字の識別子は支配的な規則であり、私の推奨事項です。引数 isn't 伝統 - it's の堅牢性。 slack に貼り付けられたログ、端末、コード レビューのコメント、およびスタック オーバーフローの回答で構文の強調表示が消えます。大文字のキーワードは、テキストとともに伝わる強調表示です。反論 (小文字のすべて、エディターに強調表示させます) は一貫性があり、I've はそれを喜んで使用したコードベースで動作しました。What's が一貫していないのは混合であり、選択を強制するフォーマッターがなければ、これが得られます。
1 行につき 1 つの節、インデントされた内容。 最も高い利益を持つ構造規則。 SELECT 行を開始します。その列は下にインデントされます (短い場合は同じ行)。 それぞれ JOIN 独自の行を取得します ON 条件が表示されている - 結合条件が隠されている 正中線は、間違った結合バグが隠れている場所です。 WHERE 条件を並べて並べて、1 行に 1 つ積み重ね AND/OR 各行を先頭に導き、論理構造が垂直に読み取られるようにします。 クエリの条件が列として読み取られると、欠落している条件が パターンのギャップ、人間の目は非常にスポッティングが得意です。
コンマ戦争。 後続のコンマ (各列の後) は自然に読み込み、先頭のコンマ (各列の前、行開始時) は、句読点を構造化します。
-- Trailing (most common)
SELECT
u.id,
u.email,
o.total
-- Leading (the DBA classic)
SELECT
u.id
, u.email
, o.total
Leading-comma advocates have two guenely good points: commenting out any line except the first never breaks the statement, and a missing comma is instantly visible at the left margin. lealing-comma advocates have one: それはあなたが書く他のすべての言語のように見えます。 私は末尾のコンマを書いて、それについて悪い気分をやめました - しかし、SQLは現代のJavaScriptやPythonとは異なり、そうすることに注意してください でないよ 最後の列の後にぶら下がっているコンマを許してください、それはこの議論がまったく存在し、なぜ主導的なスタイルがDBAサークルで死ぬことを拒否する理由です 完全な開示: Toolz.devフォーマッタは主流側を取り、トレーリングカンマを放ちます - それはリーディングカンマモードを持っていないので、もしあなた& #39; コミットされたリーディングカンマショップは、これがそれが勝った1 つの慣習です& #39; tはあなたのために再フォーマットし、家のスタイルを選択し、一貫して適用し、次に進みます。
フォーマットができないこと。 最適化されません。 フォーマットされた SELECT * 5 テーブル結合には、見事にインデントされたパフォーマンスの問題があります。 フォーマットは、 前提条件 最適化には、読み取れないクエリについて推論することはできませんが、推論には依然として必要です EXPLAIN、インデックスの認識、そしてデータの形を知る。 パイプラインを次のように考えています。 EXPLAIN、次に最適化します。 ステップ 1 をスキップしても、速くはなりません。2 ～ 4 のステップを遅くします。 同じ分野が API に 1 つのレイヤーを適用します。そのため、 JSON フォーマッタ ガイド ペイロードについて構造的に同じ議論をします。
コメントは生き残る。 ミニ化とは異なり、書式設定はコメントを保持します - -- LINE コメントと /* */ ブロックはそのまま通り抜けます。 それらを使用してください。 あ -- deliberately LEFT JOIN: include customers with no orders 参加の上にあるコメントは、これまでに書かれた最も安いバグ保険であり、私の 340 行のホラー ストーリーが必要なコメントです。
よくある使用例
コードレビュー
プルリクエストでフォーマットされていないSQLは、 isn& #39; t going to happen - the reviewer& #39; s eyes slide off the wall of text and the approval lands anyway. PRを開く前にクエリをフォーマットすることは、測定可能な利得を伴う基本的な礼儀です: 結合タイプ、条件グループ化、および列リストは個別に表示され、それはそれらが個別にレビュー可能になることを意味します すべての本物のSQLバグI& #39; レビューに引っかかった - 間違った結合、括弧なし OR、 DELETE 半分が欠けている WHERE 条項 - クエリが行ごとに読み取れるほど十分にフォーマットされていたため、私は捕まえられました。
ORM 生成クエリのデバッグ
ORMはエンドポイントが遅くなるまで素晴らしいです、その時点で実際のSQLを見る必要があります - そしてORM出力は常に1 つの密な行です フォーマットするとストーリーが表示されます: 熱心なロードが逃したN + 1、サイレントに追加された関係の定義を結合、 ORDER BY インデックスなしの列に。 ララヴェルの仕事では、これは週に数回の儀式です: 望遠鏡、コピー、 フォーマット、ひるみ、雄弁なコードを修正して、繰り返します。 フォーマッタは何も診断しません。クエリを十分に読みやすくします。 君 できます。
レガシー クエリに関する考古学
すべての長寿命のシステムにはそれらがあります: 2015 年からのストアドプロシージャ、誰も触れる勇気のないレポートビュー、元の作成者& #39; s 書式設定 (つまり、なし) で構成ファイルに埋め込まれたクエリ。 legacy SQLを変更する前に、それをフォーマットして最後まで読みます - you& #39;llは日常的にcan& #39;t ever trueの条件を見つけ、書き込みを受信しなくなったテーブルに参加し、現在のチーム& #39;sの仮定が矛盾するロジックをフォーマットします。 first turns "scary legacy query" into "long but regible query,"これは別のより良い問題です。
クエリのバージョンの比較
レポート& #39; s の番号がリリース間で変更されると、質問は " クエリで何が変更されたか、 " そして答えは2 つのバージョンを差分する必要があります - これは、最初に両方が同一にフォーマットされている場合にのみ機能します同じ設定で両方をフォーマットしてから、それらを実行します テキスト差分ツール: ノイズが消え、2 つの変更された線が独立しています。 この正確なシーケンスは、最終的に私の内部結合のバグを発見しました。 今やってます 前に 後ではなく、混乱の日半。
教育と文書化
チュートリアル、ランブック、内部ドキュメントの SQL は、作成者よりもスキーマにあまり慣れていない読者によって、書かれたよりも多くの回数読み取られます。大文字のキーワードと 1 行あたりの 1 つの概念構造を含む書式設定された例は、劇的に学習しやすくなります。この構造は、コンテンツと並行して教えます。クエリが埋め込まれたドキュメントを書くとき、誰もが最初にフォーマッターを通過します。; ドキュメント内の未フォーマットの SQL は、読者に作成者が読んだことを伝えます' 実際に読んでくれる人はいないと予想します。
フォーマットの規則を比較
| コンベンションの選択 | オプションA | オプションB | 私のテイク |
|---|---|---|---|
| キーワードケース | SELECT (大文字) |
select (小文字) |
大文字 - ハイライトなしでコンテキストを存続します |
| 識別子の場合 | スネークケース | テーブル定義に一致 | 定義を一致させ、スキーマと戦わないでください |
| カンマ | 後続 (id,) |
リード (, id) |
劣勢ですが、リードは守られます。1 つを選択するだけです |
| 句レイアウト | 1 行につき 1 つの句 | コンパクトな単線 | 過去の些細なことで、1 行につき 1 つずつ |
AND/OR 配置 |
各条件線を先導する | 前の行を引きずる | リーディング - ロジックは垂直方向に読み取ります |
| 参加条件 | ON 独自のラインまたはインラインで JOIN |
埋もれたミッドライン | 結合で表示され、常に |
| 幅の折れ | 2スペース | 4スペース | どちらか; SQL のネストが json より少ないので、ここでは 4 で問題ありません |
これらの行のどれも間違った答えを持っていない、とthat& #39; s正確に罠 - なぜなら、すべてのオプションは防御可能な、チームは永遠にそれらを再訴訟フォーマッタが機械的な決定を行わない限り、勝利の動きは退屈です: 選択、構成、フォーマットすべて、および実行計画に影響を与えるものに再生引数の時間を費やすこの1 つを中心とした毎日のツールキットの残りの部分については、を参照してください コーディング ツール ガイド そしてより広い Web 開発者ツールキット。
フェイク
SQL フォーマッタは何をしますか?
SQLフォーマッタは、query' sの空白、改行、キーワードケーシングを一貫した読み取り可能な構造に書き換えます - それぞれの節を独自の行に、条件と列をインデントし、キーワードを1 つのケースに正規化します。 statement' sの意味は触れられていません: SQLパーサーは書式設定を完全に無視するため、書式設定されたクエリは、同一の実行計画で同一の結果を返します。変更は、純粋にクエリを確認、デバッグ、保守する人間のためです。
SQL のフォーマットはクエリのパフォーマンスを変更しますか?
いいえ SQL では空白とキーワード大文字と小文字はセマンティックではありません。データベースは両方のバージョンを同じ内部表現に解析し、同じ実行計画を生成します。実行することで検証できます EXPLAIN それぞれに。 フォーマットは、パフォーマンスの仕事自体ではなく、パフォーマンス作業の前提条件です。インデックスについて理由を説明したり、読み取れないクエリで順序を結合したりすることはできません。
SQL キーワードは大文字か小文字か?
どちらも有効です - SQLキーワードは標準に従って大文字と小文字を区別しません - したがって、これは読みやすさの規則であり、正しさの規則ではありません。大文字のキーワード()SELECT、 FROM、 WHERE) は、色を剥ぎ取るコンテキストで、ログ、差分、端末、およびプレーン テキスト メッセージの中で、組み込みのハイライトとして機能するため、最も一般的な選択肢です。 どちらを選択しても、コードベース全体の一貫性は、選択自体よりもはるかに重要です。
SQL の主要なコンマとは何ですか?また、なぜ人々はそれらを使用するのですか?
先頭のカンマ スタイルでは、各列行の先頭にコンマを配置します (, email前の列の終わりではなく。最初の列を除く列をコメントアウトしても構文エラーは発生せず、欠落しているカンマが左余白に即座に表示されるため、支持者はこれを好みます。SQL は & #39; 最新の JavaScript と同様に、最後の列の後にダングリング コンマを許容しないため、実際の利点。後続のカンマは引き続き一般的です; どちらかが一貫して適用されていれば機能します。
Eloquent や ActiveRecord などの ORM によって生成された SQL をフォーマットできますか?
はい、そしてit& #39; s フォーマッターの最良の用途の1 つ - ORMデバッグ出力は、マシン生成エイリアスを持つ単一の高密度ラインとして到着し、フォーマットすることは、遅いエンドポイントとN + 1 の問題の診断の最初のステップであるORM& #39; s ロギング (Laravel Telescope、ActiveRecordログ) からクエリをキャプチャし、 に貼り付けます SQL フォーマッタ、そして ORM が実際に構築したものを読んでから、到達する前に EXPLAIN。
フォーマッタは、MySQL、PostgreSQL、および SQL Server の構文で動作しますか?
はい - 実用的なフォーマッタは主要な方言を処理します' MySQL バックティック、PostgreSQL の二重引用符による識別子を維持したまま、奇妙な :: キャスト、および SQL Server 角括弧を書き換えるのではなく、大小括弧で書き直します。 ANSI SQL 規格は共有コアを定義しますが、本番データベースは純粋な標準 SQL を語らないため、フォーマッタが実際のクエリで役立つためには、方言の許容範囲が必要になります。
生産クエリをオンライン SQL フォーマッターに貼り付けても安全ですか?
SQL は異常に機密性が高いため、クライアント側の 1 つだけに含まれています。クエリはスキーマを公開し、ログからコピーされたクエリには、電子メールや ID などのリテラル値が含まれることがよくあります。 WHERE 条項。 ザ・ Toolz.dev SQL フォーマッタ 何も送信または保存されていない状態でブラウザ内のすべての処理を行います - 貼り付けている間に「ネットワーク」タブを見て自分で確認します。実稼働環境から何ものでもサーバーベースのフォーマッタは避けてください。
フォーマットすると SQL コメントが保持されますか?
はい - 両方 -- LINE コメントと /* */ ブロック コメントは、削除する縮小とは異なり、そのまま通します。 これにより、コメントが意図される注釈付きクエリやストアド プロシージャに対して書式設定が安全になります。 それを使用してください: 意図的なことを説明する単行のコメント LEFT JOIN または、異常な状態は、破損していない次の開発者の「修正」に対する最も安価な保護です。
