A Non-Technical Reason to Not Use SELECT *

I got a merge a while back that included a change I wasn’t expecting from one of my developers. All they were doing was renaming a column on a table. We had names settled a while ago. What’s up with that?

Turns out, when I created the table, I named one of the fields BrithYear. This merge request corrected it to BirthYear. The misspelling slipped past me, past everyone else, it was only discovered because when this developer was building the a new query into their code, they spelled the field as one would expect, and the query threw an error.

SELECT * wouldn’t have done that for this developer. Specifying field names saved the day here. If they hadn’t caught that issue, we’d have been stuck with an embarrassing typo in the database for a long time. But even further, products like Red Gate SQL Data Catalog which attempt to classify your data in part by pattern-matching on filenames, would probably skip right past this one.

Sure, there are technical reasons to not use SELECT *. Column reordering and the performance impact of fetching more data than you actually need come to mind immediately (although if you need every column, SELECT * is no worse for performance than specifying them by name).

But protection from your DBA making a typo is a pretty good benefit too.