31

人々がテーブル エイリアスをどのように使用しているか知りたいです。私が働いている他の開発者は、常にテーブル エイリアスを使用し、常に 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 を使用します。

4

16 に答える 16

22

テーブルの別名を使用する理由は 2 つあります。

1つ目は化粧品です。テーブルのエイリアスを使用すると、ステートメントが書きやすくなり、おそらく読みやすくなります。

2番目はより本質的です。テーブルが FROM 句に複数回出現する場合は、それらを区別するためにテーブル エイリアスが必要です。自己結合は、同じテーブルの主キーを参照する外部キーがテーブルに含まれている場合に一般的です。

2 つの例: スーパーバイザーの employeeID を参照する SupervisorID 列を含む employees テーブル。

2つ目はパーツ爆破。多くの場合、これは ComponentPartID、AssemblyPartID、Quantity の 3 つの列を持つ別のテーブルに実装されます。この場合、自己結合はありませんが、多くの場合、このテーブルとパーツのテーブルへの 2 つの異なる参照の間で 3 方向の結合が行われます。

身につけるのは良い習慣です。

于 2008-10-13T16:52:17.440 に答える
20

入力を節約するためにそれらを使用します。ただし、関数に似た文字を常に使用します。したがって、あなたの例では、次のように入力します。

SELECT t.TripNum, s.SegmentNum, s.StopNum, s.ArrivalTime 
FROM Trip t, Segment s 
WHERE t.TripNum = s.TripNum

私にとっては、それだけで読みやすくなります。

于 2008-10-13T16:39:41.227 に答える
6

通常、ストアド プロシージャでは複数の結合が行われるため、原則として常にそれらを使用します。また、CodeSmith などのコード生成ツールを使用してエイリアス名を自動的に生成する場合も簡単になります。

a や b の文字で始まるテーブルが複数ある可能性があるため、a や b のような 1 文字を避けるようにしています。私はより長いアプローチを採用し、参照された外部キーとエイリアス テーブルを連結します。たとえば、CustomerContact ... これは、Contact テーブルに結合するときの Customer テーブルのエイリアスになります。

長い名前を気にしないもう 1 つの理由は、ほとんどのストアド プロシージャがコード CodeSmith によって生成されているためです。自分で作成しなければならないかもしれないいくつかを手で入力してもかまいません。

現在の例を使用すると、次のようになります。

SELECT TripNum, TripSegment.SegmentNum, TripSegment.StopNum, TripSegment.ArrivalTime 
FROM Trip, Segment TripSegment 
WHERE TripNum = TripSegment.TripNum
于 2008-10-13T16:51:28.597 に答える
3

すでに数年前の議論に追加できますか?

誰も言及していない別の理由があります。特定のデータベースの SQL パーサーは、エイリアスを使用するとより適切に機能します。オラクルが後のバージョンでこれを変更したかどうかは思い出せませんが、エイリアスに関しては、データベース内の列を検索して記憶していました。テーブル名に関しては、ステートメントで既に検出されていたとしても、データベースの列を再チェックしていました。そのため、エイリアスを使用すると、特に長い SQL ステートメントの解析を高速化できました。これがまだ当てはまるかどうか、他のデータベースが解析時にこれを行うかどうか、変更された場合はいつ変更されたかを誰かが知っていると確信しています。

于 2010-06-17T14:55:49.990 に答える
1

単純なクエリでは、エイリアスは使用しません。複数のテーブルがあるクエリでは、次の理由で常にそれらを使用します。

  • それらはクエリをより読みやすくします(私のエイリアスはテーブル名のショートカットであり、可能であれば他のテーブルとの関係である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 ...
于 2009-08-04T19:16:10.920 に答える
1

私はいつもそれを使用します、理由:

  • ステートメントに完全なテーブル名を残すと読みにくくなります。さらに、同じテーブルを 2 回持つことはできません。
  • 何も使用しないことは非常に悪い考えです。後で、他のテーブルに既に存在するテーブルの1つにフィールドを追加できるからです。

次の例を検討してください。

select col1, col2
from tab1
join tab2 on tab1.col3 = tab2.col3

ここで、数か月後、「col1」という名前の列を tab2 に追加することにしたと想像してください。データベースはそれを暗黙のうちに許可しますが、tab1.col1 と tab2.col1 の間のあいまいさのために、上記のクエリを実行するとアプリケーションが壊れます。

ただし、命名については同意します。a、b、c は問題ありませんが、例ではts の方がはるかに優れています。同じテーブルが複数ある場合は、t1、t2、... または s1、s2、s3... を使用します。

于 2008-10-13T17:11:58.913 に答える
0

私が学んだことの 1 つは、特に複雑なクエリの場合です。すべてのフィールド参照の修飾子としてエイリアスを使用すると、6 か月後のトラブルシューティングがはるかに簡単になります。次に、そのフィールドがどのテーブルから来たかを思い出そうとしていません。

とてつもなく長いテーブル名を使用する傾向があるため、テーブルに別名を付けた方が読みやすいと思います。もちろん、派生テーブルや自己結合を使用している場合は、これを行う必要があるため、習慣化することをお勧めします。私たちの開発者のほとんどは、すべての sp の各テーブルに同じエイリアスを使用することになるので、ほとんどの場合、それを読んでいる人は、どの pug が mmh のエイリアスであるかをすぐに知ることができます。

于 2008-10-13T21:24:58.293 に答える
0

私はいつもそれらを使用しています。以前は、1 つのテーブルのみを含むクエリでのみ使用していましたが、a) 1 つのテーブルのみを含むクエリはまれであり、b) 1 つのテーブルのみを含むクエリが長期間そのままになることはめったにないことに気付きました。そのため、私(または他の誰か)が後でそれらをレトロフィットする必要がないように、常に最初からそれらを入れています. ああ、ところで:SQL-92標準に従って、私はそれらを「相関名」と呼んでいます:)

于 2008-10-14T08:14:22.510 に答える
0

できるだけ頻繁に使用する必要があると思いますが、t と s が a と b よりも適切にエンティティを表すことに同意します。

これは、他のすべてと同様に、好みに要約されます。各開発者が同じ方法でエイリアスを使用する場合、同じ規則に従ってストアド プロシージャに依存できることが気に入っています。

同僚を説得して、あなたと同じ考えを持ってもらいましょう。さもなければ、これはすべて無意味です。別の方法として、テーブル Zebra を最初のテーブルとして使用し、それを a としてエイリアスすることもできます。それはただかわいいでしょう。

于 2008-10-13T16:39:12.007 に答える
0

フィールドがどのテーブルから来ているかを区別するために必要な場合にのみ使用します

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 などを使用します。

于 2008-10-13T16:46:01.913 に答える
0

テーブルのエイリアスは次の 4 つにする必要があります。

  1. 短い
  2. 有意義
  3. 常に使用
  4. 一貫して使用

たとえば、service_request、service_provider、user、およびaffiliate (その他多数) という名前のテーブルがある場合、これらのテーブルに「sr」、「sp」、「u」、および「a」というエイリアスを付けることをお勧めします。可能なすべてのクエリで。これは、よくあることですが、これらのエイリアスが組織で使用されている頭字語と一致する場合に特に便利です。そのため、「SR」と「SP」がそれぞれサービス リクエストとサービス プロバイダーの用語として受け入れられている場合、上記のエイリアスは、テーブルとそれが表すビジネス オブジェクトの両方を直感的に表す二重のペイロードを持ちます。

このシステムの明らかな欠点は、まず a_long_multi_word_table_name のように a_long_multi_word_table_name のように almwtn などのエイリアスになるような、多くの「単語」を含むテーブル名が扱いにくいことです。 . 最初の欠陥は、最後の 3 文字または 4 文字を使用するか、最も代表的である、最もユニークである、または入力しやすいと思われるサブセットを使用するなど、好きなように対処できます。私が実際に見つけた 2 番目の方法は、見た目ほど面倒ではありません。運が良かっただけかもしれません。また、account_type との競合を避けるために、account_transaction を「at」ではなく「atr」にエイリアスするなど、表の「単語」の 2 番目の文字を取得することもできます。

もちろん、上記のアプローチを使用するかどうかにかかわらず、エイリアスは非常に頻繁に入力するため、短くする必要があります。また、単一のテーブルに対してクエリを作成してエイリアスを省略した後は、エイリアスを常に使用する必要があります。重複する列名を持つ 2 番目のテーブルで後で編集する必要があることは避けられません。

于 2008-10-21T20:19:36.097 に答える
0

好みに過ぎないと思います。前述のように、エイリアスを使用すると、特に長いテーブル/ビュー名を入力する手間が省けます。

于 2008-10-13T16:59:21.780 に答える
0

フルネームを使用すると、特に大きなクエリや Order/Product/OrderProduct シナリオで読みにくくなります0

私は t と s を使います。または o/p/op

SCHEMABINDING を使用する場合は、とにかく列を修飾する必要があります

ベース テーブルに列を追加すると、修飾により、クエリで重複する可能性が減少します (たとえば、「コメント」列)。

この修飾のため、常にエイリアスを使用することは理にかなっています。

a と b を使用することは、奇妙な基準に盲従することです。

于 2008-10-13T17:00:23.913 に答える
-1

いつも。習慣にしてください。

于 2008-10-13T16:41:04.263 に答える