すべてのツール

SQLフォーマッタ/ビューティファイア

SQLコードを簡単にフォーマットして美しく整形し、読みやすさと保守性を向上させるSQLフォーマッターツールです。

2件中5件の評価

SQLフォーマッタ/ビューティファイアは、SQLコードを読みやすく、一貫したレイアウトに整える無料ツールです。

SQLを整形すると何が変わりますか？

SQLを整形すると、句や式、入れ子構造を追いやすい見た目に変わります。一般に、SELECTリスト、JOIN句、WHERE条件、サブクエリ、CASE式などに改行やインデントが追加されます。

整形によって、クエリが意図する結果が変わることは想定されていません。ただし、SQLの方言には違いがあり、整形しただけでは文の意味が維持されていると証明できません。生成されたSQLを本番データに対して実行する前に、必ず内容を確認してください。ベンダー固有の演算子、手続き型の拡張機能、特殊な引用符の規則を使用している場合は、特に注意が必要です。

フォーマッタは、第三者が書いたクエリを読むとき、生成されたSQLをレビューするとき、長い文をデバッグするとき、プルリクエスト用にコードを整えるときに役立ちます。レイアウトを統一すると、無関係な空白の差分が減り、変更箇所も比較しやすくなります。

SQLを整形するにはどうすればよいですか？

SQL欄にSQL文を貼り付けるか入力し、送信すると、整形された内容が美化されたSQLに表示されます。入力内容は処理のためHTTPS経由でサーバーに送信されますが、保存されません。

残しておく必要がある共通テーブル式を含め、文全体をコピーします。結果にコメントと終端のセミコロンが維持されていることも確認してください。
可能な限り、断片だけを整形するのではなく、文全体をSQL欄に入力します。
美化されたSQLの結果を読み、特に入れ子になった式と方言固有の構文を確認します。
デプロイする前に、適切な開発環境またはステージング環境で整形後の文を実行します。

digily.link のSQLフォーマッタ/ビューティファイアツールと入力フォーム

機密性の高いデータベース作業では、クエリのテキストをサーバー型ツールに送信する前に、組織のポリシーを確認してください。クエリを理解するうえで不要なら、パスワード、アクセストークン、個人データ、機密情報を含むリテラル値を削除します。

整形されたSQLはどう読めばよいですか？

整形後のレイアウトを文の正しさの証明とは考えず、インデントと句の区切りをたどって読みます。最上位のSELECT、FROM、WHERE、GROUP BY、ORDER BYは、論理的な各部分が別の行やインデント階層に分かれることで、通常は見分けやすくなります。

インデントされたサブクエリを見ると、内側の結果が外側の文のどこで使われているか分かります。
揃えて表示された条件では、ANDとORの優先順位を確認しやすくなります。ただし、既定ではANDがORより優先され、論理的なグループ分けは引き続き括弧で決まります。
分けて表示されたJOIN句を見ると、各ON条件がどのテーブルに対応しているか把握しやすくなります。
展開されたSELECTリストでは、カンマの不足、列の重複、曖昧な別名に気付きやすくなります。
明確に分かれたCASEの分岐は、WHEN、THEN、ELSE、ENDの各キーワードの対応を確認するのに役立ちます。

引用符で囲まれた文字列、数値、句読記号、コメントにはSQL上の意味があります。単なる表示上の要素だと思い込まず、内容を確認してください。アクセント付き文字やラテン文字以外の文字も、データベースと文字エンコーディングによっては、文字列リテラルや引用符で囲まれた識別子の中で有効です。

簡単な整形例

次のようなコンパクトな入力を考えてみます。

入力: SELECT id,name FROM customers WHERE active=1 ORDER BY name;

読みやすく整形すると、次のように表示できます。

出力: SELECT id, name

FROM customers

WHERE active = 1

ORDER BY name;

JOINを含むクエリでは、インデントの効果がさらに分かりやすくなります。

入力: SELECT o.id,c.name FROM orders o JOIN customers c ON c.id=o.customer_id WHERE o.total>100;

読みやすい出力では、比較式o.total > 100を維持したまま、SELECT、FROM、JOIN、ON、WHEREを別々の行に配置できます。大文字と小文字の使い分け、空白、改行位置は整形規則によって異なるため、この例は保証された標準スタイルではなく、レイアウト例として参照してください。

SQLのエラーも見つけられますか？

いいえ。SQLの整形は、データベースのパーサーによる検証とは異なります。このツールが返すのは整形されたSQLであり、構文チェッカー、スキーマチェッカー、実行プランナーとしては使用できません。

ただし、レイアウトが明確になることで、レビュー中に間違いと思われる箇所を見つけやすくなる場合があります。よくある例として、SELECTリストのカンマ不足、対応していない括弧、閉じられていない引用符付き文字列、本来の条件がないJOIN、誤ってグループ化されたANDまたはORの式があります。予約語を引用符なしの識別子として使っている箇所も見つけやすくなることがあります。

対象のデータベースがなければ判断できない問題もあります。PostgreSQLで受け入れられる文でも、Microsoft SQL Server、MySQL、Oracle Database、SQLiteでは変更が必要な場合があります。存在しないテーブル、不明な列、互換性のないデータ型、権限エラーの診断には、通常、データベースエンジンまたは対象の方言に対応した開発ツールが必要です。

SQLを整形しなくてもよいのはどんな場合ですか？

SQLがすでに一貫した形式で整えられている場合や、機械だけが処理する場合は、通常、整形し直す必要はありません。生成されたクエリを再整形すると、そのクエリを作ったジェネレーターは改善されないまま、ソース管理上の不要な差分だけが増えることがあります。

次のような状況でも、整形は適切な手順ではない場合があります。

移行ファイルに署名やチェックサムが付いている、またはバイト単位で比較されている。
最小化されたクエリやコンパクトなクエリがサイズ制限の厳しい成果物に埋め込まれていて、人がレビューする必要がない。
当面の作業目的が読みやすさの改善ではなく、検証、実行プランの分析、パフォーマンスチューニングである。
組織のポリシーにより、サーバー型サービスへの送信が認められていない機密値がクエリに含まれている。

リポジトリ全体を同じ規則で繰り返し整形するなら、設定をコードと一緒にコミットできる、SQL方言対応のコマンドラインフォーマッタのほうが適している場合があります。SQLを含む構造化されたAPIペイロードでは、JSONバリデーター＆整形ツールを使うと周囲のJSONを確認できますが、SQL自体は引き続きSQL専用の方法で処理する必要があります。

よくある質問

SQLを整形するとNULLの動作は変わりますか？

空白やインデントによって、SQLの三値論理やNULLの動作が変わることはありません。ただし、column = NULLのような式は確認してください。通常はIS NULLを使う必要がありますが、フォーマッタはこの意味上の誤りを修正しません。

複数のSQL文をまとめて整形できますか？

複数のSQL文を一度に処理できるとは明記されていません。文ごとに分けて整形してください。

入力にコメントを残しても安全ですか？

実行可能なSQLに機密性の高いリテラルがなくても、コメントにはチケット番号、内部ホスト名、顧客情報、運用上のメモが含まれている場合があります。テキストをサーバーに送信する前に、行コメントとブロックコメントの両方を確認してください。

SQLキーワードは大文字と小文字のどちらで書けばよいですか？

多くのデータベースエンジンでは、引用符で囲まれていないキーワードの大文字と小文字を区別しないため、通常はどちらでも問題ありません。リポジトリで採用されている規則に従ってください。引用符で囲まれた識別子については、大文字と小文字を保持または区別するデータベースもあるため注意が必要です。

整形したクエリを実行する前に何を確認すべきですか？

対象データベースのSQL方言を確認し、WHERE条件とJOIN条件を点検してください。UPDATE、DELETE、スキーマ変更文では、トランザクションの境界も確認します。リスクのあるクエリは、まず開発用またはステージング用データベースで実行してください。できれば、本番に近いデータと適切なバックアップを用意します。