You mean aside from ddl change, performance, network overuse, column order change, performance, indexes being useless, not seing the list of columns when working on the code?
so aside from bad design that breaks the application and abysmal performance, you want more than that?
I agree with all those opinions, but unless I have public available reference material to go with your statement it is just an opinion and has less weight than the developer in question.
We're not talking about natural law here, we're talking about something that's going to be based on annecdotal material. Any "public available reference material" on this is just going to be that author's opinion on it. If it's an author the developer considers more knowledgeable than himself, that might help, but it'll still just be an opinion.
In my particular case (and many others), the opinion is based on extensive experience, and the weighing of known costs and benefits. But it's still "just an opinion".
On the other hand, disliking severe pain is also "just an opinion", and one that's based on personal experience. Some like it. Same difference here.
I can't believe that in 40+ years of RDBMS systems reference materials that none of them back up any of the post that have been made.
That pain hurts is a medical fact and backed up by literal TONs of literature and reference material on the neverous system. It is WAY beyond opinion.
You misread what I wrote. Pain, by definition, hurts. The two words are synonymous, it would be impossible for pain to not hurt. But what I said is that it's something I dislike. There are people who enjoy pain, or at least enjoy certain types/quantities of pain. Both the S&M crowd, and "no pain no gain" exercise types, are examples.
Same thing for this.
There is no absolute "using SELECT * will cause you to get zits" or anything like that which can be quantified, stated in terms of natural law or "by definition" structure. It's a question of which do you dislike more:
Having to spend a few extra seconds now putting in a list of column names, thus potentially avoiding significant future work
Spending a few less seconds now by using an implicit column list, potentially having to do a lot of future work to fix problems this causes
Personal preferences on readability of one vs the other is also a question of opinion. I prefer an explicit column list most of the time, because that is "self-documenting", but there are indeed times when the column list is long enough to be annoying. I always list them, for consistency, but I do recognize this is a personal preference.
You won't find something that can say, "Just like you cannot move faster than light, you must use an explicit column list in SELECT statements". If it does exist, the author was either being ignorant, humorous, or making some sort of point other than the one explicitly written.
The predominance of opinion amoungst people with long-term experience in this field is use explicit lists. But it is an opinion. The predominance of this can be confirmed easily through Google or Bing or whatever.
The thing to keep in mind is that "Earth being destroyed and everyone on it dying would be bad" is also an opinion. It's not a provable scientific fact. "Just an opinion" is a very misleading statement, is the point I'm making here.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon