Hacker News Reader

Comment by twoodfin | Hacker News Reader

Most of the rules seem reasonable, but what's the justification for this?

Rule_L031: Avoid table aliases in from clauses and join conditions.

I can't see what makes aliases clarifying in `select` or `where` but not in `join`. Also, inlined subqueries in a join must be given an alias, so there are cases where this rule can't be applied consistently.

View on HN

I think it depends on if your table names are readable or not. If you table names are "sales" and "orders" then I would argue that makes the sql a lot more readable i.e

sales.amount orders.due_date

s.amount ord.due_date

In the second example I have to flip back and forth between the join statement in order to know where the columns are coming from.

If you have awful table names though like qq123xc then I think aliasing would be appropriate

The moment you have the same table used more than once as a table source (in a JOIN) then this goes out the window.

Moreover, there's nothing wrong with saying `SELECT ... FROM sales sales ...`.

Wholeheartedly agree with this. The problem isn't aliasing, it's lazy aliasing which is more I think what GP was referring to (e.g. emp.id instead of employee.id).

Yes, that's often important. Project at work has lots of tables with very long names, which I alias frequently to obvious short names:

    schema.adjective_noun_adjective_noun as anan

Aliases rarely add clarity in my experience. An alias is just an extra lookup when I need context. It’s a waste of mental swap space.

Inlined subqueries are creating entirely new projections so they need descriptive names. If you are doing this you should consider a WITH anyway.

This rule is no good.

Reply on news.ycombinator.com