I fear programmers will miss the big picture that a top-quality book often provides
There're a couple of problems with that statment... first, there are disappointingly few programmers and a lot of folks who think they are. Second, there are very few "top-quality" books out there. Most of them are simple regurgitations of Books Online and maybe a couple of oolies here and there. You mention several authors by name and there are a couple of them who are apparently more enamoured with writting a book than writting a top-quality book about SQL Server. Those authors should take up writting romance novels instead of trying to write anything of technical use or to promulate understanding rather than sometimes rude opinion.
There's also the problem of "lunacy" in many of the books. I'll refrain from identifying the books or the authors who published such lunacy, but I saw one book that talked about creating databases where the author went to some length saying that because SQL Server would automatically grow the files, there was absolutely no need to plan the initial size of a production database. Nowhere did he mention that the default growth patterns would result in 73 disk fragments just growing to a mere 1GB. Several highly respected authors have published ways to do running totals and running counts... and all of them used bloody Triangular Joins and of the ones that even came close to identifying the performance problems associated with such joins, they merely downplayed the problems by saying you have to be careful about how many rows you use it on without any mention to alternatives. And then there're my favorite books on performance tuning... you know... the ones where authors show you how to build a test table... using a &^%^$^##! WHILE LOOP!
Most DBA's I know are really smart cookies. Some of them are Systems DBA's, some are Application DBA's (super Ninja Developers on steroids, really), and some are hybrids. I don't know very many good SQL Server developers, but the ones I do know are absolute Ninja's at their trade as well. When any of those folks see a book with such garbage as what I've described in it, they're simply not going to buy it. When they see a book written by a frustrated romance novelist instead of a pro who's "been there", they're just not going to buy it.
The rest of the folks I know that are (still trying) to be DBA's or SQL Developers really don't give a rat's patooti as to whether they do a good job or not. I've had two developers (God, I really hate to call them that... it's an insult to good developers) with MS certs as DBA's and they had zero interest in improving what they called "skills" even though they couldn't program their way out of a wet paper bag nor hit the ground with their hat when it came to tuning the server never mind indexes.
Top that off with the fact that the really good DBA's are more interested in Books Online and the technical manuals that came with their servers and SANs, and you just don't have much of a market for DBA books. Add to that that you can't cut and paste from hardcopy and, unless a book comes with a CD that no one ripped off, it's just easier to get the information you need from the internet.
I do have one book that I refer newbies to and will let them borrow with some great threat that assures it's safe return because it's way out of print and I'm not sure you can even get it anymore. It's the old MCSE book on Implementing SQL Server 7.0 and, no, the new books carrying a similar name are garbage compared to that old book.
As a side bar... I think that it's a real shame that, IMHO, there are no good books on SQL Server. Sure, many of them have their high spots but, for the most part, the garbage and the unnecessary rhetoric in them make them all very not worth while spending between $40 and $100 bucks for. And, to be sure, I'm not singling out any of the authors on that... heh... I think they're all a huge let down for one reason or another.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs