ORDER BYの前に空白がありません - これはなぜ機能しますか？

Question

"ORDER BY"節の前にスペースがないアプリケーションでSQLを見つけました。私はこれがうまくいくことにも驚きました。整数のインクリメントリストで、このSQLは、これはまた、文字列を使用していますのMicrosoft SQL Server 2012の

select 
* 
FROM [counter] c 
where c.counter_id = 1000ORDER by counter_id 

で正常に動作します1列、counter_idは、単にそこにある。ここで、[カウンター]と呼ばれる数値のテーブルを、与えられた

例えば：

WHERE some_string = 'test'ORDER BY something 

私の質問は、任意の潜在的な落とし穴や危険性は、このクエリを使用してありますか？逆に、何か利点はありますか？その空白（何らかのアプリケーションではよく考慮されるかもしれない）のネットワークトラフィックの8ビットはどれくらい保存されますか？

Answer 1

私は、これは数値と文字列で動作する理由を説明しましょう。

名前がエスケープされていない限り、数字は識別子を開始できないためです。基本的に、SQLクエリに起こる最初のことはトークン化です。つまり、クエリのコンポーネントは、識別子とキーワードに分割され、次に解析されます。

SQL Serverでは、キーワード、識別子、および関数名などは、数字で始めることはできません（名前がエスケープされていない限り）。したがって、トークナイザが数字に遭遇すると、数字があることがわかります。この数字は、数字以外の文字に遭遇したときに終了します。したがって、1000ORDER BYのような一連の文字は、簡単に3つのトークン、1000,ORDERおよびBYに変換されます。

同様に、一重引用符が最初に検出されたときは、常に文字列リテラルを表します。文字列リテラルは、最後の一重引用符が見つかると終了します。次の文字セットは別のトークンを表します。

これらのニュアンスを使用する理由はまったくありません。まず、これらのルールはSQL Serverのトークン化のプロパティであり、必ずしも他のデータベースには適用されません。第二に、SQLの目的は人の人間が照会を表現できるようにすることです。それは私たちが読むより重要なやり方です。

Answer 2

jarlhはトークンのスキャンと解析中に違いがあるかもしれませんが、したがって、それは長所や短所

Answer 3

パーサは文字を調べるに大きな違いではないかもしれません、それはキーワード、識別子、文字列定数をチェックし、言語の全体的なセマンティックと構文構造に一致します。 'Order by'はキーワードであり、sqlパーサーはクエリ内で可能な構文上の位置を知っているので、エラーを投げずにそれを解釈します。これは、あなたの注文が何のエラーも投げない理由です。 Parsing sql query

Parsing SQL