Is it always a good practice to use aliases in sql joins or nested queries?

Question

Is it always a best practice to use -

Select E.Id,D.DeptName from Employee E join Dept D on E.DeptId=D.Id

instead of -

Select Employee.Id,Dept.DeptName from Employee join Dept on Employee.DeptId=Dept.Id

Other than readability and reducing length of the query what are benefits of using aliases ? When I consulted with our Database expert he says query may break if there are no aliases at times...which I dont understand completely...I would appreciate if anyone would share their thoughts and what are the best practices to be followed...Thanks a lot.

Answer 1

When you reference the same table twice, you have to use an alias.

Other than that, there isn't any technical reason I can think of.

Answer 2

The most readable way is to be explicit with a fully qualified name; on that your DB expert and I agree.

But when you're developing them... aliases are your friend, hands down.

Answer 3

1. Increases readability
2. Provides a way to join the same table on different join condition

Answer 4

I almost always do it because I hate to type out the full table name, and if you don't do it you can end up with ambiguous column names. Just don't use meaningless aliases such as t1, t2, etc.

Answer 5

1. You are probably confusing "needing to use a table prefix" and "needing to use an ALIAS" when referring to breaking things.

   The query might indeed be more likely to break after adding a join if you don't use a table prefix; when your original table and a newly added table share a column with the same name. So for the sake of future maintenance, always using a table prefix is a GOOD idea for all columns in the query.

   However, this problem is solved by using ANY table prefix in front of columns, whether real table name or alias name.

2. The alias is needed (as opposed to actual table name) when you use the same table twice.

3. From a lot of experience with maintaining lots of complex SQL, I must say that my view is 100% opposite of yours.

   Namely, using a short - especially 1-letter - table alias makes for a HARDER to read/maintain code.

   When you're debugging a long piece of SQL with complex joints at 2am in the morning during production emergency, looking back/forth 10-15 lines above to see what table matches alias "e" is MUCH harder.

   This point has 2 exceptions

   • when the business logic of the query uses the table for a purpose which is VERY distinct from the table name.

   • when the table name is unreasonably long and unreasonable due to circumstances beyond your control - and then the alias should still be something readable and logical. E.g. "EmployeeTableIndexedByUIDSourcedFromHR" can and usually should be aliases as "Employee", but not as "E"

4. Also, to avoid having overly long strings, it helps hreatly if you format your queries using newlines and alignment:

   Select Employee.Id,Dept.DeptName from Employee join Dept on Employee.DeptId=Dept.Id

vs

SELECT  Employee.Id
       ,Dept.DeptName
FROM    Employee
JOIN    Dept
ON      Employee.DeptId=Dept.Id

Answer 6

I prefer to use the fully qualified table names in most cases. I usually only use an alias name for tables if a inner join is required between two tables in separate databases, just to make it a little more readable.

Select  Employee.Name, sales.Amount
From    Employee
        Inner Join SalesDB.dbo.Sales as Sales On Employee.ID = Sales.EmployeeID

However, I would recommend using alias names for your fields in order to prevent changes required to calling applications down stream.

Select Employees.Name as [Name]
From   Employees