dglynch21;10990791 wrote:The SELECT is a shortcut to select all the columns, why not use it if you need to select all the columns?
If you actually need to SELECT all columns, now and forever (such as in a 'INSERT INTO... SELECT FROM' type of query), then it might not be a bad idea.
However, more often than not this isn't the case. For example, can you predict the future and know that just because you're using data from every single column (you are, aren't you?) in the present that your needs will always adapt in the future with the table schema? Most likely not.
Also, say you're modifying a piece of code and you come across a query like:
SELECT * FROM users;
Can you answer all (or even any?) of these questions:
How many columns does that table have?
What are the names of the columns that you're using?
What type of data do you expect those columns contain?
How is data in this table referenced/related in other tables?
Assuming you came to the same conclusion I did (you can't answer any of those questions), you'll see that 'SELECT *' queries can actually do more harm than good.
Plus, we haven't even considered the possible performance impact introduced by making the SQL server first lookup the column names of the table since we didn't provide them in the query.
dglynch21;10990791 wrote:Would this not be an easy way to code it?
"Easy"? Definitely. Does the "easy" way always (or even regularly) coincide with the "best", or "robust", or even "correct" wait? Not so much. :p