SQL: Using Select * [duplicate]

Question

Possible Duplicate:
Which is faster/best? SELECT * or SELECT column1, colum2, column3, etc.

Is it bad practice to use Select * ?

I was going through some old code and saw some 'SELECT *' statements. My previous coworker had told me Select * was bad practice, but I couldn't really see the reason why (unless of course I only needed to return a few fields). But for full 'detail retrieves' (Get by Id type queries) Select * seems right.

Answer 1

It's bad practice.

If your schema changes down the road, the calling application may get more fields than it knows what to do with.

Also, you are getting more info than you need, which affects performance.

Also also, it implies you don't know what the columns are.

Answer 2

Using SELECT * is bad practice for two reasons:

• It can return extra columns that you don't need, wasting bandwidth
• It can break your code if someone adds a column

Answer 3

Yes, Select * is a bad practice. For one, it is not clear to other developers which columns you really are using. Are you actually using all of them? What happens when you add columns are you using those too? That makes it much more difficult to refactor column names should that need arise. Second, there are some instances where some database systems will remember which columns existed at the time you created an object. For example, if you create a stored procedure with Select *, it will bake in the columns that exist in the table at the time it is compiled. If the table changes, it make not reflect those changes in the stored procedure. There really isn't any reason to use Select * beyond laziness.