Hacker News Reader

Comment by Hjfrf | Hacker News Reader

Your first question is fairly common too- select * is to be avoided if your table can change or you care about order of columns.

Select * is better from cte/temp table because you then only need to make changes in one place.

I'm not sure how much deeper it's possible to go.

View on HN

I agree wildcards are better avoided but so are column orders in result extraction. They are a source of bugs and much review work when changes are made.

If I had to choose (which usually isn't necessary) I'd say wildcards are the lesser evil.

it's becoming increasingly more common to sort columns at the application layer

I agree. Applications that rely on the ordering of columns are as bad as people who complain when I add a new column into, or change the ordering of a CSV which has column headers. There is no technical reason to do this; computers are ample fast enough to look up columns by name!

>computers are ample fast enough to look up columns by name!

Sure, but depending on number of records and/or implementation of the name lookup, it can add up over a large resultset, or have a slightly cost over many smaller queries.

Mind you, I think -most- implementations are smart enough to only need to do the lookup once for a returned datareader, but the cost is still there.

> so are column orders in result extraction.

While I agree, there are some languages + db drivers where this is your only choice unless you roll your own. Go's sql package relies on order in the Scan method, for example.

"care about the order of your columns" is a far bigger red flag than "select *".

Reply on news.ycombinator.com