SQLフォーマッター

標準SQL、MySQL、PostgreSQL、Oracle、SQL Server、SQLite、BigQueryに対応しており、各ダイアレクト固有のフォーマットルールとキーワード処理を適用します。

はい、ストアドプロシージャ、ユーザー定義関数、トリガー、複雑なプロシージャブロックを処理し、BEGIN/END、IF/ELSE、LOOP構文に適切なインデントを適用します。

はい、難読化機能を使って機密性の高いテーブル名、カラム名、値をプレースホルダーテキストに置き換え、クエリ構造を維持したまま安全に共有できます。

アナライザーはSQLを検査し、ステートメントタイプ、参照テーブル、複雑度評価、キーワード使用状況、パフォーマンス特性を特定してクエリの最適化を支援します。

はい、複数のステートメントを含むSQLスクリプト全体を処理し、各SELECT、INSERT、UPDATE、DELETE、DDLステートメントを個別に適切に区切ってフォーマットします。

フォーマットルールは選択した方言に適応します：MySQL/MariaDB、PostgreSQL、T-SQL (SQL Server)、SQLite、Oracle PL/SQL。主な違いは、キーワードセット（LIMIT vs TOP vs FETCH FIRST）、識別子の引用符のスタイル（バッククォート vs ダブルクォート vs 角括弧）、ステートメント区切り文字であり、フォーマッターは方言が要求する形式をそのまま維持します。

デフォルトでは予約語（SELECT、WHERE、JOIN）を大文字にし、識別子は記述どおりのままにします。これはSimon Holywellが管理している広く引用されるスタイルガイドをはじめ、多くのSQLスタイルガイドで採用されている慣習です。カンマ先頭 vs 末尾の配置と、行頭でのAND/ORの整列は、コードレビューにおけるdiffの可読性に最も影響を与える2つのオプションです。

いいえ。変更されるのは空白と予約語の文字ケースのみで、リテラル、識別子、コメント、あるいはパフォーマンスヒントとして短絡評価が依存し得る論理演算子の配置が変わることは決してありません。フォーマット後のクエリは同じエンジン上で同じ実行プランを生成しなければなりません。生成されない場合は、意味的な選択ではなくフォーマッターのバグです。