SQL: Using Select * [duplicate]

Answer 1

If any schema changes occur (extra columns are added), these will be caught by your application. This might be undesirable, say, if you bind a grid dynamically to a DataTable. Also it incurs more overhead on network communications.

Even if you are selecting all columns as of today, define the columns by name - its readable and explicit. Any additional columns will then not cause any problems with your code.

Answer 2

Even if you need to select all columns it is still better to specify them rather then use 'select *'

Answer 3

Yes, it is deemed bad practice.

It is better to specify an explicit column list, especially if the table contains many columns and you only really need some of them.

Answer 4

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 5

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 6

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.