3 ms·
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
by twoodfin 5y ago
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.
- mulmen 5y agoAliases 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.
- pwildenhain 5y agoI 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 vs 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
- cryptonector 5y agoThe 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 ...`.
- Orou 5y agoWholeheartedly 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).
- cryptonector 5y agoThis rule is no good.
- mixmastamyk 5y agoYes, 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