Our team have been working on a number of whitepapers for SQL Server 2008. On of the first of these out the door is Itzik Ben-Gan's new paper on the T-SQL enhancements. It's great reading and can be found at:
I got to work with Ron Talmage on the new partitioning whitepaper. Watch for it soon too.
I had a note from Bill Graziano this morning telling me that our spotlight sessions for the PASS Summit in Seattle in November have been posted, along with details of some of the other sessions. I'm really looking forward to the summit this year as I had to miss TechEd at the last minute. Details are here:
I had an interesting note from David Silverlight today pointing out the INETA Community Champion awards. I'd encourage all to take a look at them, at the prizes and see if you should be participating. Details at: http://www.community-credit.com/cs/blogs/community_credit_news/archive/2008/06/17/the-ineta-community-champion-award.aspx
I know this post has the potential for religious-level debate but it's time to make it anyway.
The more I've been working with Analysis Services lately, the more it grates on me that the BI community still seem to be the last ones hanging onto table prefixes. They're not doing "tblSomeTable" but they are using "dim", "fact", etc.
Hasn't the time for this long gone now?
Most of the argument seems to be about finding tables in a list of tables. You could do that via schemas if you really wanted to. But as Adam Machanic pointed out recently, from 2005 onwards many-to-many dimensions blur these lines anyway.
Is it time for the prefixes to go?
A few weeks ago I managed to catch the tail end of the reptiles series that Sir David Attenborough created. If you have a spare 3 1/2 minutes, take a look at this video: http://www.bbc.co.uk/sn/tvradio/programmes/lifeincoldblood/video.shtml?licbtt08
People seem to think crocodiles are cold, unintelligent eating machines. This video clearly shows they doing something that I'd suggest that more than 99% of humans couldn't do, even with pen, paper and a calculator with weeks of notice and a library at their disposal. What fascinates me is how they sense when to do this, given the combination of events happens so infrequently. Yet they arrive and set aside their territorial squabbles for just a day or two at exactly the right time.
Crocodiles have always intrigued me. I grew up not too far from Steve Irwin's place at Beerwah. Whatever anyone ever thought of him, I found that if you watched him in action in person, I have never seen anyone more mesmerising.
Clearly, there's a lot more to this world that we don't understand yet. That's what I love about science. It's not the answers that are the best part, it's the questions. I sense that we know so very little as yet.
I had heard a lot of praise for Scott Ambler's book: Database Refactoring: Evolutionary Database Design over the past few years. It's another relatively classic book that I've been slow to read.
I often mentioned to people that when I was at a software design review meeting for Microsoft around the DataDude product (Visual Studio Team Edition for Database Professionals), I noticed that Sachin Rekhi from the team was walking around with a copy of this book under his arm. As Sachin was responsible for the refactorings to go into the product and there was only one (rename) at the time, I thought that was a good sign for where the product might head. I wasn't aware that he had been a contributor to the book. Sachin wrote some of the opening details.
Now that I've read it, I'd have to say I was underwhelmed by it. I really liked the idea that someone would tackle this topic as it's sorely needed in the database community where I endlessly see DBAs who feel like they can never change anything in their schemas. I spend a lot of time with DBAs discussing how they might "regain control" of their databases to avoid this.
The biggest problem I see with the book for a SQL Server DBA's use is that Scott has (understandably) focussed on lowest-common-denominator approaches, mostly using triggers to achieve everything he does. The code samples are all from Oracle and I'm sure that wouldn't help many although they wouldn't be that hard to translate. But in the end, it's often just the wrong approach. For example, he talks about how to introduce calculated columns as a refactoring, again using triggers to maintain them. But calculated columns have been part of SQL Server since 2000 and 2005 introduced persisted calculated columns. Each type of these is automatically maintained by SQL Server and each has a different use case.
That's really the problem with the book. While the concepts are great, most of the book is filled with the "how and why" and the "how" is often far from what you'd want to do when working with SQL Server and the "why" is also often off the mark. Another example is his splitting of tables horizontally which would have been better done via table partitioning since SQL Server 2005.
So, in the end, I was left with very mixed feelings on the book. For DBAs who might not have been exposed to unit testing, test driven development, agile methodologies, etc. this might provide a reasonable introduction in a database context. But I wouldn't want to see SQL Server DBAs following the advice on exactly what to do.
This is another one of those books I picked up in an airport when I ran out of reading material while travelling. One of the key criteria I applied when choosing the book was whether or not I'd finish reading it by the time we landed. We had a bit of a delay boarding so I'd definitely finished it by the time we'd landed. It's in the "quick reads" series and it is just that.
I'm quite a fan of Richard Branson. There's something about his larrikin nature that I admire. Perhaps it's that I don't do these things enough myself. In the book Screw It, Let's Just Do It – Lessons in Life, Richard describes his outlook on life and business. I really was hoping for more insights into the guy. I did mildly enjoy it and found many of the stories interesting, particularly the section on his criminal past. I was unaware of it.
It's ok for passing an hour or two.
I haven't posted up any book reviews recently so it's time to catch up a bit. For some reason, it had taken me ages to get to read Kalen's latest book in the Inside SQL Server series: Inside Microsoft SQL Server 2005 – Query Tuning and Optimization.
As expected, it's a great piece of work. I very much enjoyed the chapters written by other authors as well, particulary those from Adam Machanic and Craig Freedman. Ron Talmage, Sunil Agarwal and Lubor Kollar have also made strong contributions to this work.
I had wondered what outcome the book would aim for. I found it to be more of a good coverage of many of the things you need to know and have a good understanding of when doing performance tuning, moreso than one that provides a pragmatic approach to what you need to do. Perhaps that's another book. This book ceratinly provides the background knowledge of much of the internals involved.
Highly recommended reading!
I've posted show 36 for SQL Down Under with guest SQL CAT team leader Lubor Kollar up at the site (www.sqldownunder.com). In the show, Lubor discusses the SQL CAT team and some SQL Server 2008 features such as the resource governor and compression.
It was great to see an announcement from Francesco Ballena today that his VB to VB.net conversion tool has finally hit the market. It's at www.vbmigration.com and looks like the sort of tool that was needed when VB.NET was first released. It sure would have avoided a lot of angst in the community. I was particularly impressed by the quote at http://www.vbmigration.com/Blog/default.aspx. I'd have to say I could definitely relate to the sentiment expressed in it. Congratulations Francesco!
After 15 years of developing our application in VB3, VB4-16 bit and VB6, I was disappointed to discover that we could not move to VB.Net. Our application was too large to rewrite into the new syntax. In spite of edits made to follow the new rules, such as omitting the lower bound on Dim statements, the migration tool available ran for 5 hours and gave 1947 errors to fix; and that was just on our main application program. Using VB Migration Partner, we converted that same code to .Net in 9 minutes and had 3 compilation errors to fix, all having to do with a third-party OCX. After commenting out those lines, the application started up and ran just fine, displaying dialogs that invoke our VB6 COM servers to perform calculations and print reports. Amazing! We need to keep developing our code in VB6 for our current clients, but the batch processing and code-test-fix methodology will allow us to convert a changing code base without making the same changes twice, once in VB6 and again in VB.Net.