sql - SQLテーブルエイリアス-良いか悪いか？

Question

SQLでテーブルエイリアスを使用することの長所と短所は何ですか？私は個人的にそれらを避けようとしています。なぜなら、それらはコードを読みにくくするからです（特に、大きなwhere / andステートメントを読むとき）が、これに対する反論を聞くことに興味があります。テーブルエイリアスを使用するのが一般的に良いのはいつですか。また、好みの形式はありますか？

Answer 1

高度に正規化されたスキーマを処理する場合、テーブルエイリアスは必要悪です。たとえば、私はこのDBのアーキテクトではないので、我慢してください。人の名前、住所、電話番号、所属会社などのクリーンで完全なレコードを取得するには、7回の参加が必要です。

やや標準的な単一文字のエイリアスではなく、短い単語のエイリアスを好む傾向があるため、上記の例のSQLは次のようになります。

select person.FirstName
      ,person.LastName
      ,addr.StreetAddress
      ,addr.City
      ,addr.State
      ,addr.Zip
      ,phone.PhoneNumber
      ,company.CompanyName
from tblPeople person
left outer join tblAffiliations affl on affl.personID = person.personID
left outer join tblCompany company on company.companyID = affl.companyID

...など

Answer 2

1つのクエリで同じテーブルに2回結合する必要がある場合など、それらを使用する必要がある場合があります。

また、テーブル全体で一意の列名があるかどうかにも依存します。従来のデータベースでは、すべての列に3文字のプレフィックスがあり、テーブルの省略形に由来しています。これは、かつて互換性があった1つの古いデータベースシステムがテーブルエイリアスを十分にサポートしていなかったためです。

複数のテーブルに存在する列名がある場合は、列参照の一部としてテーブル名を指定する必要があります。したがって、テーブルエイリアスを使用すると、構文を短くすることができます。

Answer 3

彼らを心から憎んでいるのは私だけだろうか？

通常、必要がない限り使用しません。次のようなものを読まなければならないのが本当に嫌いです

select a.id, a.region, a.firstname, a.blah, b.yadda, b.huminahumina, c.crap
from table toys as a
inner join prices as b on a.blah = b.yadda
inner join customers as c on c.crap = something else
etc

SQL を読むときは、自分が何を選択しているのかを正確に知りたいと思っています。エイリアスは実際にはもっと混乱します。なぜなら、実際にテーブル名にたどり着く前に列の行をたどらなければならないからです。テーブル名は通常、エイリアスには含まれないデータに関する情報を表します。エイリアスを作成しても問題ないかもしれませんが、StackOverflow に関する質問で、特に理由もなくエイリアスを使用しているように見えるコードをよく読みます。(さらに、誰かがステートメントでエイリアスを作成し、それを使用しないことがあります。なぜですか?)

多くの人がタイピングを嫌うので、テーブルエイリアスが多用されていると思います。いい言い訳にはならないと思うけど。その言い訳が、ひどい変数名、ひどい関数の頭字語、悪いコードになってしまう理由です...私なら時間をかけて完全な名前を入力します。でも、私はタイピングが速いので、それが関係しているのかもしれません。(おそらく、将来、手根管ができたときに、エイリアスに関する私の意見を再考します。:P) 私は特に、PHP コードでテーブルのエイリアスを実行するのが嫌いです。それを行う必要がある理由はまったくないと信じています -一度入力するだけです！

私はステートメントで常に列修飾子を使用しますが、大量に入力することを嫌うわけではないので、喜んで完全な名前を複数回入力します。（確かに、私はMySQLのタブ補完を悪用しています。）エイリアスを使用しなければならない状況でない限り（他の回答で説明されているように）、抽象化の追加レイヤーは面倒で不要です。

編集：（1年以上後）エイリアスを使用するいくつかのストアドプロシージャを扱っています（私はそれらを作成しておらず、このプロジェクトは初めてです）、それらはちょっと面倒です。エイリアスが嫌いな理由は、エイリアスがどのように定義されているかということだと思います。スコープの先頭で変数を宣言するのが一般的にどのように良い方法か知っていますか? (そして通常は行の先頭に?) SQL のエイリアスはこの規則に従っていないため、歯ぎしりします。したがって、単一のエイリアスのコード全体を検索して、それがどこにあるかを見つける必要があります (イライラするのは、エイリアス宣言を見つける前にロジックを読まなければならないことです)。それがなかったら、正直このシステムの方が好きだったかもしれません。

他の誰かが対処しなければならないストアド プロシージャを作成する場合は、参照として、ファイルの先頭にあるコメント ブロックにエイリアスの定義を入れています。正直なところ、あなたたちがそれなしで夢中にならない方法が理解できません。

Answer 4

良い

以前にも何度も言及されているように、すべての列名にプレフィックスを付けて、どの列がどのテーブルに属しているかを簡単に確認することをお勧めします。エイリアスは完全なテーブル名よりも短いため、クエリが読みやすく、理解しやすくなります。もちろん、適切なエイリアシングスキームを使用する場合。

また、外部に保存された、または動的に生成されたテーブル名を使用するアプリケーションのコードを作成または読み取る場合、エイリアスがないと、これらすべての「％s」または他のプレースホルダーが何を表すかを一目で判断するのは非常に困難です。これは極端なケースではありません。たとえば、多くのWebアプリでは、インストール時にテーブル名のプレフィックスをカスタマイズできます。

Answer 5

Microsoft SQLのクエリオプティマイザーは、完全修飾名またはエイリアスのいずれかを使用することでメリットがあります。

個人的に私はエイリアスを好みます、そして私がたくさんのテーブルを持っていない限り、それらは一文字のものである傾向があります。

--seems pretty readable to me ;-)
select a.Text
from Question q
    inner join Answer a
        on a.QuestionId = q.QuestionId

SQL文字列を実行できる時間にも実際的な制限があります。エイリアスを使用すると、この制限を簡単に回避できます。

Answer 6

自分でクエリを作成する場合（デザイナーを使用せずにエディターに入力することにより）、テーブル名には常にエイリアスを使用するため、完全なテーブル名を1回入力するだけで済みます。

すべての列名のプレフィックスとして完全なテーブル名を使用してデザイナーが生成したクエリを読むのは本当に嫌いです。

Answer 7

彼らに本当に反対しているのは、過度の抽象化だけだと思います。エイリアスが何を指しているのかがよくわかっている場合（適切な命名は役立ちます。「a」、「b」、「c」は、特に数か月または数年後にステートメントを読んでいるときに非常に問題になる可能性があります）、何も問題はありません。エイリアシングあり。

他の人が言っているように、同じテーブル（またはビュー）を複数回使用している場合、結合には結合が必要ですが、その状況以外でも、エイリアスは特定のコンテキストでのデータソースの目的を明確にするのに役立ちます。エイリアスの名前で、データが何であるかではなく、特定のデータにアクセスしている理由に答えるようにしてください。

Answer 8

エイリアスが大好きです!!!! それらを使用した場合と使用しない場合のテストをいくつか行ったところ、処理の向上が見られました。私の推測では、大規模なデータセットと複雑なネストされたクエリを扱っている場合は、そうでない場合よりも処理が向上します。これをテストできたら、お知らせします。

Answer 9

テーブルをそれ自体に結合する場合、またはサブクエリで列を再度使用する場合は、これらが必要です...

Answer 10

私の組織が SchemaName.DataPointName_SubPoint_Sub-SubPoint_Sub-Sub-SubPoint... のようなテーブル名を持っていることを考えると、エイリアスは素晴らしいものです。ProgramInformationDataPoint は pidp に短縮され、サブミッションは単に sub.

良いことは、この方法で作業を開始し、人々がそれに同意すると、HAYUGE ファイルが少し小さくなり、管理しやすくなることです。少なくとも私にとっては、同じ情報を伝える文字数が少ないほど、頭が少し楽になるようです。

Answer 11

IMHO、意味のある短いテーブル名では実際には問題ではありません。テーブル名がVWRECOFLYや、実際にユーザーを表すその他のランダムな文字列（会社のポリシーで指定）のようなデータベースで作業したことがあります。その場合、エイリアスはコードをはるかに読みやすくするのに本当に役立ちます。（users.usernameは、VWRECOFLY.usernameよりもはるかに多くの意味を持ちます）

Answer 12

私は多くのテーブルを使用し、名前が明示的でない場合、各テーブルが何を格納するかについて混乱する可能性があるため、長い明示的なテーブル名（100文字を超えることは珍しくありません）が好きです。

したがって、クエリを作成するときは、クエリの範囲内で意味があり、コードをはるかに読みやすくする短いエイリアスを使用する傾向があります。

Answer 13

私は常にクエリでエイリアスを使用しており、これは会社のコード ガイドブックの一部です。結合するテーブルに同じ名前の列がある場合、まずエイリアスまたはテーブル名が必要です。私の意見では、エイリアスは複雑なクエリの可読性を向上させ、各列の場所をすばやく確認できるようにします。経験上、単一テーブル クエリは単一テーブルのままでは長く続かないことがわかっているため、単一テーブル クエリでもエイリアスを使用します。

Answer 14

クエリを作成するときは常にエイリアスを使用します。通常、私はテーブル名を1文字または2文字の代表的な文字に省略しようとします。したがって、Usersはuになり、debtor_transactionsはdtなどになります。

タイピングを節約し、それでもいくつかの意味を持ちます。

名前が短いほど、私にも読みやすくなります。

Answer 15

MSSQL で適切なパフォーマンスを得るには、常にスキーマのプレフィックスを付ける必要があるため、常にエイリアスを使用します。たくさん見られますので、

dbo.Person から
Person.Name を Person として選択

Answer 16

エイリアスを使用しない場合は、発生するのを待っているコードのバグです。

SELECT Description -- actually in a
 FROM
 table_a a,
 table_b b
 WHERE
 a.ID = b.ID

Description という名前の列を Table_B に追加するなど、ちょっとしたことをするとどうなるでしょうか。そうです、エラーが発生します。列を追加しても、何も壊れる必要はありません。私は、良いコード、バグのないコードを書くことを必要悪とは考えていません。

Answer 17

同じ名前の列を持つテーブルを結合する場合は、エイリアスが必要です。