クエリの構造を見やすくする
SQL 文はキーワード、識別子、リテラル、演算子などのトークンから成ります。空白や改行はトークンを区切ることが多く、句読記号にも固有の意味があります。MultiVerto のフォーマッターは一般的な句の前に改行を加え、SELECT name,score FROM results WHERE score>10 ORDER BY score DESC を読み取りやすくします。レビューする人は、選択列、参照表、条件、並び順を別々の判断として確認できます。圧縮ツールは逆に、トークンのテキストを保ちながら余分な空白を減らします。どちらのツールもデータベースでクエリを実行せず、results が実在する表か、score が意図した型かも検証しません。出力は読みやすさのための補助であり、正しさの証明ではありません。
具体的な SELECT 文を確認する
スコアが 10 を超える結果を高い順に表示するレポートを考えます。SQL を整形すると SELECT、FROM、WHERE、ORDER BY が別々の行に現れるため、比較条件が 10 より厳密に大きい値だけを選ぶのか、10 も含めるべきなのかを確認できます。SQLite の文書が説明するように、ORDER BY がなければ返される行の順序は未定義の場合があります。短縮したクエリーは小さなテスト用データに保存しやすいかもしれませんが、実行計画や索引の使用状況は分かりません。整形したクエリーを実際のデータベース環境で実行し、結果を既知のテストケースと比べてください。文字列の整形だけでは、その実行による検証に代わりません。
- SELECT 文を読みやすく整形する
- WHERE 条件と ORDER BY の意図を確認する
- 対象のデータベースでテストする
コメントと文字列を保つ
SQL の文字列と引用符で囲まれた識別子を、普通の単語のように途中で分割してはいけません。二つのハイフンで始まる行コメントは改行まで続きます。その改行を不用意に削除したり移動したりすると、コメントに含まれる範囲が変わり得ます。現在の MultiVerto の SQL 整形ツールは、配置を推測する代わりにコメントを含む文を拒否します。短縮ツールはコメントと改行の境界を保ちますが、使用前には結果を確認してください。SQL の方言ごとに引用符や特殊な文字列構文も異なり、ブラウザー内の小さなツールがすべてのベンダー拡張に対応することはできません。原文を残し、最終的な検証には対象データベース自身のパーサーを使います。
整形は安全性の検証ではない
見やすく整形されたクエリでも、意図しない行を返したり、安全でない方法で組み立てられたりします。信頼できない入力を SQL 文字列に連結し、整形したから安全だと考えてはいけません。適切な場面ではデータベース API のパラメーターを使います。公開する例に認証情報や本番環境の秘密を貼り付けないでください。ローカルの編集欄はブラウザー内で動きますが、入力済みの埋め込みリンクを共有すると、URL のフラグメントにある入力を読者が見られます。文を変更するときは、空白とは別に条件、結合、件数制限を確認します。圧縮された SQL は暗号化ではなく、業務上の処理内容を隠す手段にもなりません。ここでは読みやすい形と短い表現を比較するために使います。
対象のデータベースで確かめる
まずコメントを含まない短い SQL クエリーのコピーを用意し、下のツールで整形します。引用符で囲まれた文字列、識別子、演算子、句読記号が保たれたか確認してください。コメントや特定の製品だけが使う構文があるなら、その SQL 方言に対応する整形器を使うか、元のクエリーを変えずに残します。次に安全な試験用データベースで、score が 10 と 11 のような境界値を含む代表的な行を使って実行します。変更を適用する前に、返るデータ、順序、性能を比較してください。その後に短縮する場合は、その出力も試験します。テキストの変換は人が意図を読む助けになりますが、実際の動作を決めるのはデータベースとデータです。