tags:

views:

2771

answers:

16

What are the pros and cons of using table aliases in SQL? I personally try to avoid them, as I think they make the code less readable (especially when reading through large where/and statements), but I'd be interested in hearing any counter-points to this. When is it generally a good idea to use table aliases, and do you have any preferred formats?

+11  A: 

Well, there are some cases you must use them, like when you need to join to the same table twice in one query.

It also depends on wether you have unique column names across tables. In our legacy database we have 3-letter prefixes for all columns, stemming from an abbreviated form from the table, simply because one ancient database system we were once compatible with didn't support table aliases all that well.

If you have column names that occur in more than one table, specifying the table name as part of the column reference is a must, and thus a table alias will allow for a shorter syntax.

Lasse V. Karlsen
A: 

IMHO, it doesnt really mater with short table names that make sense, I have on occasion worked on databases where the table name could be something like VWRECOFLY or some other random string (dictated by company policy) that really represents users, so in that case I find aliases really help to make the code FAR more readable. (users.username makes a lot more sence then VWRECOFLY.username)

Adam Lerman
+13  A: 

Table aliases are a necessary evil when dealing with highly normalized schemas. For example, and I'm not the architect on this DB so bear with me, it can take 7 joins in order to get a clean and complete record back which includes a person's name, address, phone number and company affiliation.

Rather than the somewhat standard single character aliases, I tend to favor short word aliases so the above example's SQL ends up looking like:

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

... etc

Rob Allen
"Necessary Evil" seems a bit strong. At worst, its not necessary and at best it is necessary to use them. However, most of the time, using aliases adds to the readability of the code.
ScottCher
A: 

I like long explicit table names (it's not uncommon to be more than 100 characters) because I use many tables and if the names aren't explicit, I might get confused as to what each table stores.

So when I write a query, I tend to use shorter aliases that make sense within the scope of the query and that makes the code much more readable.

GoodEnough
+2  A: 

You need them if you're going to join a table to itself, or if you use the column again in a subquery...

Shawn Simon
+4  A: 

Microsoft SQL's query optimiser benefits from using either fully qualified names or aliases.

Personally I prefer aliases, and unless I have a lot of tables they tend to be single letter ones.

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

There's also a practical limit on how long a Sql string can be executed - aliases make this limit easier to avoid.

Keith
+3  A: 

If I write a query myself (by typing into the editor and not using a designer) I always use aliases for the table name just so I only have to type the full table name once.

I really hate reading queries generated by a designer with the full table name as a prefix to every column name.

BTB
A: 

I always use aliases, since to get proper performance on MSSQL you need to prefix with schema at all times. So you'll see a lot of

Select Person.Name From
dbo.Person As Person

Stu
A: 

Aliases are required when joining tables that columns with identical names.

Juha Syrjälä
A: 

I always use aliases when writing queries. Generally I try and abbreviate the table name to 1 or 2 representative letters. So Users becomes u and debtor_transactions becomes dt etc...

It saves on typing and still carries some meaning.

The shorter names makes it more readable to me as well.

Craig
+3  A: 

I suppose the only thing that really speaks against them is excessive abstraction. If you will have a good idea what the alias refers to (good naming helps; 'a', 'b', 'c' can be quite problematic especially when you're reading the statement months or years later), I see nothing wrong with aliasing.

As others have said, joins require them if you're using the same table (or view) multiple times, but even outside that situation, an alias can serve to clarify a data source's purpose in a particular context. In the alias's name, try to answer why you are accessing particular data, not what the data is.

Sören Kuklau
A: 

Aliases are required when joining tables that columns with identical names.

@Juha:

Not necessarily aliases but at least table prefixes are required to distinct columns from others with identical names.

binOr
Agreed that there is a difference between table aliases and qualifying a column... but they go hand in glove. It would be silly to alias a table and still use the table name in select list. it's equally silly to use the table name ad nauseum in the select list when SQL allows for meaningful aliases
+1  A: 

I always use aliases in my queries and it is part of the code guidebook in my company. First of all you need aliases or table names when there are columns with identical names in the joining tables. In my opinion the aliases improve readability in complex queries and allow me to see quickly the location of each columns. We even use aliases with single table queries, because experience has shown that single table queries don´t stay single table for long.

+2  A: 

Aliases are great if you consider that my organization has table names like: SchemaName.DataPointName_SubPoint_Sub-SubPoint_Sub-Sub-SubPoint... My team uses a pretty standard set of abbreviations, so the guesswork is minimized. We'll have say ProgramInformationDataPoint shortened to pidp, and submissions to just sub.

The good thing is that once you get going in this manner and people agree with it, it makes those HAYUGE files just a little smaller and easier to manage. At least for me, fewer characters to convey the same info seems to go a little easier on my brain.

Pulsehead
+1  A: 

If you do not use an alias, it's a bug in your code just waiting to happen.

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

What happens when you do a little thing like add a column called Description to Table_B. That's right, you'll get an error. Adding a column doesn't need to break anything. I never see writing good code, bug free code, as a necessary evil.

Agree, but the alias is not the point, it's the table name qualification. So without an alias this could have been written: SELECT table_a.Description
WW
Agreed that there is a difference between table aliases and qualifying a column... but they go hand in glove. It would be silly to alias a table and still use the table name in select list. it's equally silly to use the table name ad nauseum in the select list when SQL allows for meaningful aliases
+2  A: 

Good

As it has been mentioned multiple times before, it is a good practice to prefix all column names to easily see which column belongs to which table - and aliases are shorter than full table names so the query is easier to read and thus understand. If you use a good aliasing scheme of course.

And if you create or read the code of an application, which uses externally stored or dynamically generated table names, then without aliases it is really hard to tell at the first glance what all those "%s"es or other placeholders stand for. It is not an extreme case, for example many web apps allow to customize the table name prefix at installation time.

Krzysztof Sikorski