September 24, 2008 at 1:44 am
Without thinking I qualify the column names of a table when using SELECT instead of using SELECT *, because this is best practice/more efficient, I have learned. But I have never wondered why this is so.
Can any1 explain this for me?
Greetz,
Hans Brouwer
September 24, 2008 at 3:40 am
one of the reason is
optimizer will have to search the column names and its data type from the system table. It will take some extra overheard.
karthik
September 24, 2008 at 3:53 am
If you only select the columns you want, you will be returning less data (obviously).
Also, SQL Server may be able to get the columns you want from an index, without having to go to the actual data in the table, so you will get a much more efficient and performant query plan. If you do a SELECT *, it will always have to go to the table, and you are more likley to get table scans than efficient index seeks.
September 24, 2008 at 4:08 am
apart from performance benefits, it is likely that if someone else adds an additional column, there will be problems in the application because it returns more columns than desired.
September 24, 2008 at 9:48 am
Rajan John (9/24/2008)
apart from performance benefits, it is likely that if someone else adds an additional column, there will be problems in the application because it returns more columns than desired.
Or vice versa, a column removed may cause issue
Also, it's likely table A will have ID field that joins to table B which also has ID field
SELECT * will return 2 ID columns
September 25, 2008 at 12:41 am
Tnx for answering all. Glad to read there are several reasons(and good ones) for using qualified columns.
Greetz,
Hans Brouwer
September 26, 2008 at 3:13 pm
It also makes your code easier to read.
September 28, 2008 at 7:24 pm
Except in rare cases like a pass-through view (like a synonym), SELECT * will frequently (usually) make it impossible to do index seeks.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply