序数位表記、別名ordinalsは、列名または列エイリアスではなく、SELECT
句の列リストの列順序に基づく列の省略形です。 ORDER BY
句で一般的にサポートされている一部のデータベース(MySQL 3.23以降、PostgreSQL 8.0以降)は、GROUP BY
句の構文もサポートしています。
以下は、序数の使用例です。
GROUP BY 1, 2
ORDER BY 1, 2
クエリが脆弱になるため、使用するのは適切ではありません。列の順序が変更された場合は、序数を更新する必要があります。そうしないと、クエリが思ったとおりに返されません。 GROUP BY
で使用すると、それらの場所の列が集計でラップされている場合にエラーが発生する可能性があります。
私が考えることができる唯一の利点は、ストアドプロシージャまたはストアドプロシージャを使用していない場合に、ネットワーク経由で送信するデータが少ないことです(とにかく、通常の使用法を無効にします)。他に見逃しているメリットはありますか?
これは宿題のように聞こえるかもしれませんが、それは実際にはオフィスが毎月行う教育的な昼食のための研究です。彼らは昼食代を払っています、私たちは興味のある小さなトピックを提供しなければなりません。
私はそれを使用します:
利点はありません。
SQL Serverは、ORDER BYのみをサポートしています。それ以外の場所では、評価される式です。
多くの列を持つテーブルをクエリしているときはよくあります(アドホックランドでは、データ探索のためだけに... PROD環境ではこのようにコーディングすることは決してありません)気になるフィールドを取得するためにこのようなことをします一緒に閉じる:
select top 1000
Col_1, Col_18, Col_50, Col_117, *
from
TableWithTonsOfCols
order by
1, 4 desc, 3
私が言った場合order by Col_1, Col_117 desc, Col_50
"*"が2倍になるため、ステートメントはどの列を並べ替えるのかわからないため、クエリはバーフになります。あまり一般的ではありませんが、それでも便利な機能です。
私の2つのユースケースは次のとおりです。
CASE
ステートメントです。 ORDER BY
句のCASE
ステートメントを再入力するのではなく、それを保持する序数を使用します [〜#〜] dry [〜#〜] 。これを回避する方法はいくつかあります。たとえば、CTE、サブクエリ、またはビューを使用しますが、序数が最も簡単な解決策であることがよくあります。私は今インラインビューを使用する傾向があります:
select col_a, count(*) from
(select case ...... end col_a from ...)
group by col_a
order by col_a;
しかし、それらが有効な構文になる前は、列の全文を再入力するのに役立ちました。トリッキーな関数を使用すると、次のようなSELECTとORDER BYの値の間に矛盾が生じる可能性がありました。
select ltrim(col_name,'0123456789')
from table
order by ltrim(col_name,'123456789')
SELECTの「0」は、選択したもので順序付けしていないことを意味します。
クエリ生成アルゴリズムがあります-SQLは自動生成されます。序数を使用すると、フィールド名を再度取得しなくても、生成されたフィールドを参照できます。ユーザーは、画面上のリストからフィールド名を選択することにより、テーブル内のフィールド名を参照できます。リストをSQLに対応させる限り、SELECT項目も序数であれば、フィールド名を知る必要はありません。
メモリによると、これは1970年代後半のSQL標準に含まれていました。
私が正しく思い出せば、あなたが説明するような序数の使用は、SQLServerの将来のリリースでMicrosoftによって非推奨になります。私はこれについて間違っているかもしれませんが、そうだと思います。長いクエリを含む派生列を処理する場合は、入力が少なくなるため、特定のケースでそれらを使用することが常に好きでした。