Here's a few reasons why when you finalize a query, you select only the necessary columns (non-exhaustive list):
- Reduce uneccessary IO / resource strain, as you said
- Predictability; consuming program receives data in the same order, every time
- If the DBA adds additional columns to the table, it doesn't hose downstream consumer processes
- Easier to debug if some problem does arise.
- Clarity, if you are only using a few columns from a large table. I might just be getting old though ;)
Data should be served in the simplest, most robust manner.
It should be easily consumed by other services, with little extra effort from the programmer.
If you use Select *, you either accept the possibility of it breaking unexpectedly, or have to write logic within the consuming service to deal with that. If the problem can be eliminated by the DB/query itself, it should be.
I understand how clarity may provide the programmer's intention of the query but I'd rather just pick all, so that change in code below doesn't suddenly break because you didn't sync the columns to be fetched.
> - Predictability; consuming program receives data in the same order, every time
For any joined table, you can specify table name for each '*' or add an alias last to keep the column you need instead of writing it all.
Seems specifying each column name isn't in any way crtitically bad when you can't select all but a column in SQL, which is a deficiency in the language.
- Reduce uneccessary IO / resource strain, as you said
- Predictability; consuming program receives data in the same order, every time
- If the DBA adds additional columns to the table, it doesn't hose downstream consumer processes
- Easier to debug if some problem does arise.
- Clarity, if you are only using a few columns from a large table. I might just be getting old though ;)
Data should be served in the simplest, most robust manner.
It should be easily consumed by other services, with little extra effort from the programmer.
If you use Select *, you either accept the possibility of it breaking unexpectedly, or have to write logic within the consuming service to deal with that. If the problem can be eliminated by the DB/query itself, it should be.