In short, no. Aliasing is used primarily for aggregate queries, such as SELECT MAX(CreatedDate) newestAcc, AccountId accId FROM Contact GROUP BY AccountId
.
I've seen many people use table aliasing, but that's just a waste of typing, because it doesn't provide any benefit that you'd get from just using the query without aliasing. For example:
Query 1: SELECT Id, AccountId, FirstName, LastName, Email FROM Contact
Query 2: SELECT c.Id, c.AccountId, c.FirstName, c.LastName, c.Email FROM Contact c
What's the difference between these two queries? One uses more space/characters. You gain absolutely zero benefit from aliasing. As it stands today, it's literally a useless feature, and you should not attempt to use it for normal queries. You're simply wasting code space that you could use for other things.
The reason why it's useless is because we don't get joins or field comparisons that would reasonably benefit from aliasing. For example, we can't say this:
SELECT LastName, Account.Name FROM Contact C, Account A ON a.id=c.AccountId WHERE a.Name = c.LastName
Since we can't use the aliases, there's no point in having the aliases. Avoid using aliases, because they literally serve no purpose in a typical query.
The single exception to this is aggregate queries. Without aliasing, the fields become meaningless expressions like expr0
, expr1
, etc. If you're not using GROUP BY
, then aliasing has absolutely zero effect on the query. You should always alias your expressions. As a bonus, if you alias a field in an aggregate query to Id
(case sensitive), you can use the Map<Id, AggregateResult>
map constructor to automatically map results into keys, and you can also use Map<Id, AggregateResult>.put(AggregateResult[])
to a similar effect.