It’s time again for another edition of the weekly review of database blogs, Log Buffer. Since it was a big week for SQL Server, let’s start there, shall we?

The big news — SQL Server 2008 is released, as reported by SqlServer-qa.net, in seven different versions. Aaron Bertrand introduces a new kid on the block: SQL Server 2008 Web Edition — “. . . designed for highly available Internet facing web serving environments for the next generation Windows Server,” according to MS. (I’ve heard it rains quite a lot in Seattle. I guess it also Drizzles, too.) Says Aaron, “Basically, it has higher scalability than Express or Workgroup Editions : it supports up to 4 CPUs, no artificial limit on RAM, and unlimited database size.”

(Before you crack open your server case, Tara Kizer on Ramblings of a DBA has some advice on how to get physical CPU count on a server.)

The SQL Server Express Express blog helpfully offers a table outlining the differences in the features of the differences between SQL Server 2008 Express editions.

A couple little issues with the release have already emerged. Here’s Euan Garden on SQL Server 2008 Installation Confusion, VS 2008 Sp1 and NetFx 3.5 Sp1: “SQL Server 2008 has dependencies on (and includes) VS 2008 SP1 and its components (BIDS is just VS 2008, SSMS uses components), plus NetFx 3.5sp1. SQL includes the RTM versions of both of these, HOWEVER they are not broadly released yet. There is a check in SQL Server Setup that if you have an old version (Beta, RC, whatever) it will bounce the install and ask you to upgrade to the RTM bits…which of course are not yet available independent of SQL.” Click through for the KB and some other help. Denis Gobo and his readers have some more to say about this.

In all this change, you may lose sight of an important fact or two, and you may ask yourself, how did I get here . . . what version of SQL Server am I running? A couple resources are shared by Kevin Kline.

(more…)

Welcome to the 108^th edition of Log Buffer, the weekly review of database blogs.

With almost no ado at all, let’s begin with the bad news–from StatisticsIO and Jason Massie: The Death of the DBA. And who is the perpetrator of this crime? The Cloud! It sounds like something from a John Carpenter movie, doesn’t it?

Let’s see what Jason is thinking. “I’d like to retire a SQL Server DBA with 40 years experience but I don’t think that will happen. The cloud is coming and it is bad news administrators, database or otherwise.  . . . Let’s make some assumptions. The features get there. The availability gets there. The platform basically matures . . . Now put yourself in the IT decision maker’s shoes. No upfront capital expenses, no managing backups, and no patch management.  . . . If they can remove their focus from managing and deploying IT, they sell and service more widgets.”

Scary stuff, right? Well, the commenters don’t entirely agree. I think it will be at least a factor, but I wonder how many managers will look at “The Cloud” and feel uncomfortable about privacy, data retention, and the like. (For myself, I couldn’t even endorse the idea of putting this blog’s comments into “The Cloud”.) What do you think?

Elsewhere on StatisticsIO, Jason has a note about MSDN’s SQL Heroes contest, whose aim is to, “. . . create a community project in CodePlex based on SQL Server 2008.” Jason also links to a list of CodePlex’s active SQL Server projects.

Turning to matters technical, Jeff’s SQL Server Blog offers a lesson on converting input explicitly at your client: don’t rely on the database to “figure it out”. Jeff takes the example of formatting dates, and show both the right and the wrong way, writing, “I’ve said it over and over and I’ll say it again: The concept of formatting dates should never be something that your database code should ever worry about.”

On the Less Than Dot blog, SQLDenis observes that converting columns to date from datetime does not result in a scan in SQL Server 2008. What you get instead is a seek, as he demonstrates.

Indexing Foreign Keys - should SQL Server do that automatically? So asks Greg Low on the The Bit Bucket. “By adding indexes on the foreign keys on three tables,” he writes, “we saw a reduction of 87% in total I/O load.  . . . it really struck me that having SQL Server do this by default would avoid a lot of apparent performance problems.  . . .  Should SQL Server simply do this by default when you declare a foreign key reference?”

Kent Tegels of Enjoy Another Sandwich — riddle me this, riddle me that! “When is a bug not a bug?” I give up, Kent. When is a bug not a bug? (more…)