Book Review: In the Trenches with SQL Server & .NET
August 20, 2004
The Hypnerotomachia Poliphili (pronounced Hip-ner-AH-toe-mak-ee-a Poh-LI-fi-ly) is an ancient text that is the subject of a da Vinci Code style best seller named Rule Of Four. This obscure text, completed in 1499, is clearly the work of someone versed in multiple disciplines; architecture, music, painting, gardening and relationships. The nearly unpronounceable title can be translated "struggle for love in a dream," revealing Poliphilo's love for the woman who shunned him, Polia. The author is unknown.
What does this have to do with the book, In the Trenches with SQL Server & .NET? Plenty!
Last month I received an email from the publisher of
this new "In the Trenches" series book, asking if I would be
interested in reviewing it. Since I am currently hip deep in a
SQL Server / .NET project, I was happy to oblige and anxiously
awaited my copy. Coincidentally, when it arrived I happened to
be reading Rule of Four and the similarity wasn't lost on me.
Before we get to the code ...
The first things you notice are the quotes that precede each section. My favorite comes near the end of the book under the chapter on Tools. Abraham Lincoln is reported to have said, "If I had 8 hours to chop down a tree, I'd spend 6 sharpening the axe." I love that quote, and as a developer, I live by it.
Particularly in this chapter, but throughout the book, The Saint describes some of the best tools for developing SQL Server solutions with .NET. The first suggestion I put into practice revolutionized my development landscape: I began using Visual Studio .NET to develop my stored procedures. The book not only explains how to implement this solution, but why. This suggestion alone could pay for the book ten times over.
The second thing I noticed is that the format and content of this "In the Trenches" book is genuinely unique and its "trenches" claim is justified. In fact, the premise of the book is that the best tips learned in the trenches are not freely distributed.
I have to admit that I am not sure if I believe this. I have participated in news groups where no one appeared to hold back valuable advice, direction or code to newbies who asked for help. On the other hand, one might argue that we who monitor news groups and read tech books could not possibly be aware of what volume of wisdom is being withheld and I suppose there is some truth to that assertion.
An example might be the author's emphasis on methodologies, such as FDD (Feature Driven Development). Oddly enough, I no sooner read the section on Agile Development when my team leader approached me about an article he had read on the subject, moving him to suggest such a change in our methodology. The Saint took this "trench warfare" one step further, developing and describing his own flavor of this methodology, which he calls FDSD (Feature Driven Software Development). He admits that there is a dearth of tools on the market to help one implement either of these methodologies and their exact definitions are still in the process of evolution. The book includes a suggestion for how one might track development features/tasks using standard Microsoft tools like Excel or Access. Implementing evolving methodologies, I suppose, is kind of like performing surgery at a M.A.S.H. verses those done at the Mayo Clinic.
The Saint raised my hackles in the chapter on Soft Skills. While discussing how to make office politics work for you, he quoted Machiavelli who said,
Once again, I concede that the author may be on target, but it is simply not my experience. The office is not a battleground and others are not inherently my enemies. I am at war with no one and I do not believe that donning such an attitude will advance my career. If your experience more closely parallels that of the author, then this section of the book is for you. Personally, I stopped reading after the Machiavelli quote.
Ahhh ... the code
To me, the code is what it is all about, and I was by no means disappointed. Mind you, I am an experienced developer with years of T-SQL coding behind me but while reviewing one of the first snippets of code in the book I stumbled across a simple but elegant way of handling optional parameters. You know what I'm talking about. Something like this:
create proc AgentSalesSummary (@AgentID int = null) as select a.FName + ' ' + a.LName as AgentName, sum(s.SaleAmt) as Sales, sum(s.SaleAmt)/sum(s.LoginHrs) as SalesPerHour from AgentSales s inner join Agents a on a.AgentID = s.AgentID where s.AgentID=@AgentID group by a.FName, a.LName
In this proc, @AgentID is required if you want to return summary data for ONE agent, but what do you do if you want records for ALL agents? I handled this by passing -1 to represent all agents, but this is not intuitive and adds an order of magnitude to the complexity of the above code. The Saint accomplished the same thing by adding less than 20 characters to a single line in the above script. (If you are curious, write me and I'll send you the solution.)
The great part of this whole thing is that my boss, also a .NET developer on our team, called me into his office to help him solve an issue he was having with a stored proc that required an optional parameter. I quickly revealed the solution I had read in the book, In the Trenches with SQL Server & .NET and my boss, after pondering its simplicity and elegance, agreed that his problem was solved. Again, the book paid for itself.
While there were numerous suggestions and code snippets for which I have no immediate use, there were a couple that address real life issues that I face today. One was a suggestion of how to implement alerts from SQL Server using xp_cmdshell and Net Send. I now have a simple but powerful process for sending messages over the network to admin users who need to be informed of the condition of certain databases.
The last helpful code solution I will mention is something I desperately needed but had put on the back burner until I found time to research a solution. My current project is a reporting application that sometimes takes a long time to return data. Users have asked for a CANCEL button so they can abort requests that are taking a long time but I wasn't sure how to do it. I was sure it could be implemented with threading, but I had never worked with the .NET threading object so I didn't even know where to begin. The code in this "trenches" book addressed that specific problem and supplied some really slick code--code that will definitely make it into the next release of my reporter app.
Should you buy this book?
As you can see, I had mixed feelings about this book. Not the least of my reservations was the price. It carries a list price of $150 but is being sold at the introductory price of $129. That is a little steep, but the author and publishers feel it is worth it. Depending on your hourly rate, you may too. I figure the code leveraged from the book saved me 6 to 8 hours of development time already. At my consulting rate, that pays for the book several times over.
In addition, there are the intangible benefits such as improved development techniques, better programming practices and the sheer pleasure I derived from reading the book. It may not be the Hypnerotomachia Poliphili but In the Trenches with SQL Server & .NET may be just the obscure text you need in your 'struggle for excellence' as a SQL Server developer.