4 ms·
you're getting downvoted because it's not really a preference, it's pretty widely known to be bad practice and unhygienic in production queries. select * would
by __jem 3y ago
you're getting downvoted because it's not really a preference, it's pretty widely known to be bad practice and unhygienic in production queries. select * would get your pr rejected and chewed out by dba at every place i've ever worked at. so you kinda just look like you don't know what you're talking about.
- croes 3y agoIn an exists query select * is harmless, select 1 and select * result in the same execution plan at least in MS SQL. In a query than returns result rows it could break the query as soon as you add columns with names that already exist in other tables you joined in the query.
- __jem 3y agoyes, it's harmless in this position but it provides no additional benefits to the select 1 idiom and is suggestive of poor query discipline. it's far easier to say just don't ever use select * in queries.
- RHSeeger 3y agoI would add to this a bit in that 1. Given that "select " is considered something to avoid except when necessary in edge cases 2. And "select 1" will accomplish the same goal Anyone reading the "select " version of the code will have to stop and consider whether it is using "select " for a reason, because "select 1" would be the normal choice. Using "select " is assumed to be conveying some intent (that isn't there) _because_ it's not the expected way to do it. I kind of see it like if (thisField == thatField) ... vs if ( (( true || false )) && ( 11 == 11 ) && thisField == thatField ) ... Sure, they do the same thing... but you have to stop and look at the second one to make sure you're understanding what it does and if there's some reason its weird.