SQLフォーマッタ

SQL、フォーマットする言語の簡単な歴史

SQL(Structured Query Language)は1970年代初頭に IBM で Donald D. Chamberlin と Raymond F. Boyce によって開発され、もとは SEQUEL("Structured English Query Language")と呼ばれ、商標衝突後に SQL に改名されました。言語は1979年に Oracle の前身(Relational Software, Inc.)によって最初に商品化されました、Oracle V2 は最初の商用 SQL データベースで、IBM 自身の DB2 を市場で先取りしました。最初の ANSI 標準 ANSI SQL-86 は1986年に公開され、はるかに実質的な改訂 SQL-92(「大きな」SQL 標準、ISO/IEC 9075:1992)は現代のユーザーが認識する構文の大部分、JOIN 構文、集合操作、サブクエリ、トランザクションを定義しました。後の改訂はオブジェクト関係機能(SQL:1999)、XML サポート(SQL:2003)、ウィンドウ関数と CTE(SQL:2003 と 2008)、時間クエリ(SQL:2011)、JSON サポート(SQL:2016、SQL:2023 で拡張)を追加しました。各主要データベースベンダーは独自の方言を実装します、MySQL、PostgreSQL、SQLite、Microsoft SQL Server(T-SQL)、Oracle(PL/SQL)、DuckDB(PostgreSQL 互換の分析 SQL)、BigQuery、Snowflake、Redshift、ClickHouse、Databricks SQL、すべて SQL-92 コアを共有しますが、関数、構文拡張、予約語リストで分岐します。良いフォーマッタはフォーマットしている方言を尊重します、なぜなら同じ識別子がある方言ではキーワードで、別の方言では合法な列名であるかもしれないからです。

SQL を読みやすくする慣習

いくつかの慣習が SQL スタイルガイドの標準となりました、Mozilla のもの、Simon Holywell の頻繁に引用される SQL Style Guide、GitLab のデータチームの慣習、dbt の推奨スタイル。キーワードを大文字(SELECT、FROM、WHERE、JOIN)識別子(テーブル名と列名)を小文字または snake_case に対比するのが支配的な慣習です。一部のスタイルガイドは反対を主張(小文字のキーワードはタイプと読み取りが容易)、PostgreSQL 公式ドキュメントは小文字のキーワードを通して使用しますが、ほとんどのプロフェッショナルコードベースでは大文字が勝ちます、なぜなら言語構造を一目で見えるようにするからです。各主要句が独自の行に:SELECT、FROM、WHERE、GROUP BY、HAVING、ORDER BY、LIMIT、それぞれ同じインデントレベルで新しい行を始めます。JOIN 条件は ON の下にインデント:JOIN キーワードが独自の行に、ON キーワードが次の行で1レベルインデント。列リストの先頭または末尾のカンマは長く続くスタイル論争です、先頭カンマ(各列行がカンマで始まる)は列の追加/削除でより清潔な diff を生成し末尾カンマ構文エラーから保護しますが、多くの人には視覚的に異常に見えます。末尾カンマは本番コードでより一般的です。サブクエリのインデント:ネストされたクエリは親より1レベル深くインデント。CTE(WITH)句:各名前付き CTE が独自の行に、本体は AS の下にインデント、メインクエリは下に左揃えで。

SQL フォーマッタに手を伸ばすとき

• ORM がログした SQL を読む。 Hibernate、Sequelize、ActiveRecord、Prisma、SQLAlchemy、Django ORM、すべてプログラム的に SQL を生成し、アプリケーションログに密集した1行で出力します。「なぜこのクエリは遅いのか」をデバッグするには、ログされた SQL をフォーマッタに貼り付け、ORM が実際に何を生成したかを読みます。結果はしばしば啓発的(「ああ、INNER を期待した CROSS JOIN だ」)。
• データベース PR のコードレビュー。 SQL マイグレーションやストアドプロシージャ変更は、一貫してフォーマットされていると再レビューがはるかに容易です。コミット前にファイルをフォーマッタに通して、diff が空白ノイズではなく構造的になるようにします。
• クエリと並べて EXPLAIN プランを読む。 遅いクエリをチューニングするとき、EXPLAIN 出力を読み、それからクエリを読み直してプランの上部のテーブル参照を見つけます。フォーマットされたクエリは反復照合を瞬時にします。
• SQL をチケット、ドキュメント、Slack に貼り付ける。 フォーマットされたクエリは清潔に読まれます、ミニファイされた1行クエリはあらゆる狭いコンテキストで読めません。共有前にフォーマットしてください。
• 大文字小文字混合のキーワードを持つレガシークエリを再フォーマットする。 SELECT が時に Select、時に select、時に SELECT と書かれた15年のコードベースは、フォーマッタがすべてを単一の慣習に正規化した後、より良く読まれます。
• BI ツールから出力されたクエリを清掃する。 Looker、Mode、Metabase、Tableau、類似のツールは基礎となる SQL をコピーさせますが、生成する ad hoc 形式で出力します。読む前にフォーマットしてください。

SQL フォーマッタエコシステム

コマンドラインとエディタ統合ワークフローには、いくつかの成熟したオプションがあります。sql-formatter(npm パッケージ、もとは Andriy Isayev、現在はコミュニティチームが保守)は JavaScript エコシステムの支配的な SQL フォーマッタで、MySQL、PostgreSQL、SQLite、Standard SQL、BigQuery、Redshift、Snowflake、Spark、TiDB、MariaDB、その他いくつかの方言をサポートします。pg_format(Gilles Darold)は PostgreSQL 固有の標準フォーマッタで、Perl で書かれ、人気の web サービス pgFormatter にバンドルされています。Poor Man's T-SQL Formatter(Tao Klerks、2011)は Microsoft SQL Server の T-SQL 方言を特に対象とします。sqlparse(Andi Albrecht)は Python の標準ライブラリで、Django がクエリ解析に使用し、無数のデータエンジニアリングスクリプトが使用します。SQLFluff は dbt プロジェクトと分析ワークフローと統合する現代のリンター&フォーマッタです。JetBrains の DataGrip と IntelliJ IDEA の SQL プラグインは洗練された方言認識フォーマッタを含みます、VS Code の SQLTools とその他いくつかの拡張は npm の sql-formatter ライブラリをラップします。ビルドパイプラインを持つプロジェクトには、現代のパターンは「エディタでの保存時フォーマット + SQL ファイルが誤フォーマットされている場合にビルドを失敗させる CI チェック」、JavaScript の Prettier や Python の Black と同じモデル。

フォーマットに重要な方言の違い

ほとんどの SQL フォーマッタはマイナーな調整で方言を横断して動作しますが、フォーマッタがどの方言を読んでいるかを知る必要があるいくつかの違いがあります。引用符付き識別子: 標準 SQL は二重引用符を使用("order")、MySQL はデフォルトでバッククォートを使用(`order`)、ANSI モードでのみ二重引用符を尊重、SQL Server は角括弧を使用([order])。文字列連結: 標準 SQL は || を使用、MySQL は CONCAT() または ANSI モードで稀に || を使用、SQL Server は + を使用。ページネーション: MySQL/PostgreSQL/SQLite は LIMIT/OFFSET を使用、SQL Server は TOP または OFFSET FETCH を使用、Oracle は FETCH または ROWNUM を使用。自動インクリメント: MySQL では AUTO_INCREMENT、PostgreSQL では SERIAL または IDENTITY、SQL Server では IDENTITY、SQLite では AUTOINCREMENT。予約語リストは分岐します、rank という名前の列は PostgreSQL(RANK がウィンドウ関数キーワード)では引用が必要ですが、MySQL では識別子として通ります。方言を知らないフォーマッタは不適切な引用を追加して有効なクエリを壊す可能性があります。汎用フォーマッタからの「Format SQL」出力は通常、標準 SELECT/INSERT/UPDATE/DELETE 形式で正しいです、ベンダー固有構文(ウィンドウ関数、ヒント、システム関数)には、出力を方言ドキュメントと照合してください。

プライバシー、なぜブラウザ専用が SQL に特に重要か

SQL クエリはあらゆる組織で最も機微なテキストの中にあります、それらは内部テーブル名(製品分類を明らかにする)、列名(データモデルを明らかにする)、フィルタ値(実際のユーザー識別子、メールアドレス、ビジネス識別子を含む可能性)、古いパターンに埋め込まれたリテラル credentials、会社が独自と見なす可能性のある分析の構造を公開します。サーバー側 SQL フォーマッタは各クエリのコピーをログに取ります。このフォーマッタは JavaScript を介して完全にブラウザで実行されます、Format をクリックする間に DevTools の Network タブを確認(リクエストは出ません)するか、読み込み後にページをオフライン(機内モード)にしてもフォーマッタはまだ動作します。実際のテーブル名と PII フィルタ値を含む本番クエリ、内部分析 SQL、ETL パイプライン、または見知らぬ人のハードドライブにコピーされたくないクエリに安全です。

よくある質問

フォーマッタは SQL キーワードを自動的に大文字にできますか?

はい、Keywords ボタンでケースを制御します。大文字は支配的なプロフェッショナル慣習です、言語構造を一目で見えるようにするからです(SELECT、FROM、WHERE が識別子から際立つ)、小文字は一部のスタイルガイドが好みます(PostgreSQL 公式ドキュメントは通して小文字を使用)、読みやすくタイプが速いという理由で。チームが1つを選んで一貫して使用する限り、どちらも機能します。大文字化はクエリ動作に影響しません、SQL キーワードは parse 段階でケース敏感ではありません。

インデントをカスタマイズするには?

Indentation メニューは2スペース(支配的な現代 web 慣習)、4スペース(古い Java と .NET ショップで依然として一般的)、またはタブ文字をサポートします。2スペースは新しいコードベースと SQL で特に勝つ傾向があります、なぜなら深いサブクエリネストが100文字行制限内により快適に収まるからです。チームが既に使用している慣習に合わせてください、一貫性が特定の選択より重要です。

大きなクエリで動作しますか?

はい、フォーマットがブラウザで実行されるので、実用的な上限はデバイスの利用可能なメモリです。何百行もの SQL は1秒未満でフォーマットされます、何千行のクエリ(データウェアハウス ETL で典型的)は動作しますが、パーサーが構造を歩く間にタブを短時間フリーズさせるかもしれません。SQL リポジトリ全体のバッチ再フォーマットには、コマンドラインツール(npm の sql-formatter、PostgreSQL の pg_format、dbt プロジェクトの SQLFluff)がより適しています。

フォーマッタは特定の SQL 方言を認識しますか?

MySQL、PostgreSQL、SQLite、T-SQL、標準 ANSI SQL の一般的な SELECT/INSERT/UPDATE/DELETE/JOIN/CTE/サブクエリ形式を正しく処理します。ベンダー固有の構文、ウィンドウ関数句、MERGE 文、方言固有のヒント、システム関数、PostgreSQL スタイルの配列演算子、T-SQL XML メソッドは、不完全にフォーマットされる可能性があります。出力をスポットチェックし、コミット前にフォーマットされたクエリをデータベースで実行して正しく解析することを確認してください。

SQL はアップロードされますか?

いいえ。フォーマットは完全にブラウザで実行されます、貼り付けられたクエリはデバイスを離れません。Format をクリックする間に DevTools の Network タブを確認(リクエストは出ません)するか、読み込み後にページをオフライン(機内モード)にしてください。機微なテーブル名、PII フィルタ値、または NDA やコンプライアンス規制でカバーされている SQL を含む本番クエリに安全です。

関連ツール