SQLテーブルエイリアスを使用する場合
人々がテーブルエイリアスをどのように使用しているか知りたいです。私が働いている他の開発者は常にテーブルエイリアスを使用し、常にa、b、cなどのエイリアスを使用します。
次に例を示します。
SELECT a.TripNum, b.SegmentNum, b.StopNum, b.ArrivalTime
FROM Trip a, Segment b
WHERE a.TripNum = b.TripNum
私はそれらに同意しません、そしてテーブルのエイリアスはもっと控えめに使うべきだと思います。
クエリに同じテーブルを2回含める場合、またはテーブル名が非常に長く、クエリで短い名前を使用するとクエリが読みやすくなるので、これらを使用する必要があると思います。
また、エイリアスは単なる文字ではなく、わかりやすい名前にする必要があると思います。上記の例では、1文字のテーブルエイリアスを使用する必要があると感じた場合、Tripテーブルにはtを、セグメントテーブルにはsを使用します。
テーブルエイリアスを使用する理由は2つあります。
最初は化粧品です。ステートメントは書きやすくなり、テーブルエイリアスを使用すると読みやすくなります。
2つ目はより実質的です。 FROM句でテーブルが複数回出現する場合は、テーブルを区別するためにテーブルのエイリアスが必要です。自己結合は、同じテーブルの主キーを参照する外部キーがテーブルに含まれている場合に一般的です。
2つの例：スーパーバイザーの従業員IDを参照するスーパーバイザーID列を含む従業員テーブル。
2つ目は部品の爆発です。多くの場合、これは、ComponentPartID、AssemblyPartID、Quantityの3つの列を持つ別のテーブルに実装されます。この場合、自己結合はありませんが、多くの場合、このテーブルとパーツのテーブルへの2つの異なる参照の間に3方向の結合があります。
入るのは良い習慣です。
私はそれらを使用してタイピングを保存します。しかし、私はいつも機能に似た文字を使用しています。したがって、あなたの例では、次のように入力します。
SELECT t.TripNum, s.SegmentNum, s.StopNum, s.ArrivalTime
FROM Trip t, Segment s
WHERE t.TripNum = s.TripNum
それだけで読みやすくなります。
ストアドプロシージャでは通常複数の結合が行われるため、原則として私は常にそれらを使用します。また、CodeSmithなどのコード生成ツールを使用するときに、エイリアス名を自動的に生成するのが簡単になります。
Aとbで始まる複数のテーブルがある場合があるので、aとbのような単一の文字には近づかないようにしています。私はより長いアプローチをとります。たとえば、CustomerContact ...のように、参照される外部キーとエイリアステーブルを連結したものです。これは、Contactテーブルに結合するときのCustomerテーブルのエイリアスになります。
私が気にしないもう1つの理由longer nameは、ほとんどのストアドプロシージャがコードCodeSmithを介して生成されているためです。自分でビルドしなければならない可能性があるfewを手動で入力してもかまいません。
現在の例を使用して、私は次のようなことをします：
SELECT TripNum, TripSegment.SegmentNum, TripSegment.StopNum, TripSegment.ArrivalTime
FROM Trip, Segment TripSegment
WHERE TripNum = TripSegment.TripNum
すでに数年前の議論に追加できますか？
誰も言及していない別の理由があります。特定のデータベースのSQLパーサーは、エイリアスを使用するとより適切に機能します。 Oracleがこれを後のバージョンで変更したかどうかは思い出せませんが、エイリアスになると、データベースの列を検索して記憶しました。テーブル名に関しては、ステートメント内ですでに検出されている場合でも、データベースの列を再チェックしました。そのため、エイリアスを使用すると、特に長いSQLステートメントの解析を高速化できます。これがまだ当てはまるかどうか、他のデータベースが解析時にこれを行うかどうか、そして変更された場合は誰かが知っていると確信していますwhen変わりました。
単純なクエリでは、エイリアスを使用しません。複数のテーブルを使用したクエリでは、常に次の理由で使用します。
- クエリが読みやすくなります（私のエイリアスは、2つ以上の大文字です。これは、テーブル名のショートカットであり、可能であれば他のテーブルとの関係です）
- 開発と書き換えを高速化できます（テーブル名が長く、その役割に応じてプレフィックスが付きます）
例えばの代わりに：
SELECT SUM(a.VALUE)
FROM Domesticvalues a, Foreignvalues b
WHERE a.Value>b.Value
AND a.Something ...
私は書きます：
select SUM(DVAL.Value)
from DomesticValues DVAL, ForeignValues FVAL
where DVAL.Value > FVAL.Value
and DVAL.Something ...
私はいつもそれを使っています、理由：
- ステートメントに完全なテーブル名を残すと、テーブルが読みにくくなるだけでなく、同じテーブルを2回持つことはできません
- 後で他のテーブルにすでに存在するテーブルの1つにフィールドを追加できるため、何も使用しないことは非常に悪い考えです。
この例を考えてみましょう：
select col1, col2
from tab1
join tab2 on tab1.col3 = tab2.col3
ここで、数か月後、 'col1'という名前の列をtab2に追加するとします。データベースはそれを黙って許可しますが、tab1.col1とtab2.col1のあいまいさのために、上記のクエリを実行するとアプリケーションが壊れます。
しかし、私はあなたの名前に同意します：a、b、cは問題ありませんが、あなたの例ではtとsのほうがはるかに優れています。同じテーブルが複数ある場合は、t1、t2、...またはs1、s2、s3 ...を使用します。
できるだけ頻繁に使用するべきだと思いますが、t＆sはa＆bよりもエンティティを表すことに同意します。
これは、他のすべてのように、好みに要約されます。各開発者が同じ方法でエイリアスを使用する場合、同じ規則に従ってストアドプロシージャに依存できることを気に入っています。
同僚にあなたと同じページに入るように説得してください。そうしないと、すべての価値がなくなります。別の方法として、最初のテーブルとしてテーブルZebraを作成し、それをaとしてエイリアス化することもできます。それはただかわいいでしょう。
フィールドがどのテーブルからのものかを区別する必要がある場合にのみ使用します
select PartNumber, I.InventoryTypeId, InventoryTypeDescription
from dbo.Inventory I
inner join dbo.InventoryType IT on IT.InventoryTypeId = I.InventoryTypeId
上記の例では、両方のテーブルにInventoryTypeIdフィールドがありますが、他のフィールド名は一意です。
コードをわかりやすくするために、常にテーブルの省略形を名前として使用してください。ローカル変数A、B、Cなどに名前を付けるかどうか、他の開発者に聞いてください。
唯一の例外は、SQL構文にテーブルエイリアスが必要だが、それが参照されないというまれなケースです。
select *
from (
select field1, field2, sum(field3) as total
from someothertable
) X
上記では、SQL構文には副選択のテーブルエイリアスが必要ですが、それはどこからも参照されないため、遅延してXなどを使用します。
テーブルのエイリアスは次の4つです。
- ショート
- 意味のある
- 常に使用
- 一貫して使用
たとえば、service_request、service_provider、user、およびaffiliateなどの名前のテーブルがある場合、それらのテーブルに「sr」、「sp」、「u」、および「a」という別名を付けて、そうすることをお勧めします。可能なすべてのクエリで。これは、よくあることですが、これらのエイリアスが組織で使用されている頭字語と一致する場合に特に便利です。したがって、「SR」と「SP」がそれぞれサービスリクエストとサービスプロバイダーの受け入れ条件である場合、上記のエイリアスには、テーブルとそれが表すビジネスオブジェクトの両方を直感的に表すという二重のペイロードが含まれます。
このシステムの明らかな欠点は、多くの「単語」を含むテーブル名が扱いにくいことです。 a_long_multi_Word_table_name。これは、almwtnか何かにエイリアスを作成し、同じように省略されるような名前のテーブルが作成される可能性があります。最初の欠陥は、最後の3文字または4文字、または最も代表的、最もユニーク、または最も入力しやすいと感じるサブセットなど、好きな方法で対処できます。私が実際に見つけた2つ目は、おそらく運によっては、見た目ほど面倒ではありません。また、account_typeとの競合を避けるために、at_ではなくaccount_transactionを "atr"にエイリアスするなど、テーブル内の "Word"の2番目の文字を取ることもできます。
もちろん、上記の方法を使用するかどうかにかかわらず、非常に頻繁に入力するため、エイリアスは短くする必要があります。また、単一のテーブルに対するクエリを作成してエイリアスを省略した場合は、エイリアスを常に使用する必要があります。後で列名が重複する2番目のテーブルで編集する必要があることは避けられません。
それは好みに過ぎません。上記のように、エイリアスを使用すると、特に長いテーブルやビューの名前を使用する場合に、入力を節約できます。
フルネームを使用すると、特に大きなクエリまたはOrder/Product/OrderProduct scenari0の場合、読みにくくなります
Tとsを使用します。またはo/p/op
SCHEMABINDINGを使用する場合は、とにかく列を修飾する必要があります
ベーステーブルに列を追加すると、修飾により、クエリ内で重複する可能性が減少します（たとえば、「コメント」列）。
この修飾のため、常にエイリアスを使用することは理にかなっています。
Aとbの使用は、奇妙な標準に対する盲目的な服従です。
いつも使っています。以前は1つのテーブルのみが含まれるクエリでのみ使用していましたが、a）1つのテーブルのみが含まれるクエリはまれであり、b）1つのテーブルのみが含まれるクエリは、このように長く続くことはほとんどありません。そのため、私（または他の誰か）が後でそれらをレトロフィットする必要がないように、常に最初からそれらを配置します。ああ、BTW：SQL-92標準に従って、私はそれらを「相関名」と呼んでいます:)
上記の投稿には、テーブル名にエイリアスを付けるタイミングと理由について、多くの優れたアイデアがあります。他の誰も言及していないことは、メンテナがテーブルのスコープを理解するのを助けるのにも有益であるということです。当社では、ビューを作成することはできません。 （DBAに感謝します。）したがって、Crystal ReportsでのSQLコマンドの50,000文字の制限を超えても、クエリの一部が大きくなります。クエリがそのテーブルにa、b、cとしてエイリアスを設定し、そのサブクエリが同じことを行い、その中の複数のサブクエリがそれぞれ同じエイリアスを使用する場合、読み込まれているクエリのレベルを間違えやすくなります。これは、十分な時間が経過したときに元の開発者を混乱させる可能性さえあります。クエリの各レベル内で一意のエイリアスを使用すると、スコープが明確であるため、読みやすくなります。
私が学んだことの1つは、特に複雑なクエリの場合です。すべてのフィールド参照の修飾子としてエイリアスを使用すると、6か月後のトラブルシューティングがはるかに簡単になります。次に、そのフィールドがどのテーブルから来たかを覚えようとはしていません。
テーブル名が途方もなく長くなる傾向があるため、テーブルにエイリアスが付けられていると読みやすくなります。そして、もちろん、派生テーブルまたは自己結合を使用している場合は、これを行う必要があるため、習慣になっていることをお勧めします。私の開発者のほとんどは、すべてのspsの各テーブルに同じエイリアスを使用することになるので、ほとんどの場合、それを読んでいる人は、どのパグがormhのエイリアスであるかをすぐに知ることができます。
私は常にテーブルを完全に修飾するため、JOINされたテーブルが関係する場合に、SELECTされているフィールドに短い名前を付けるためにエイリアスを使用します。私のコードがわかりやすくなると思います。
クエリが1つのソースのみ（JOINなし）を処理する場合は、エイリアスを使用しません。
個人的な好みの問題。