How We Developed SQL2K8

re: How We Developed SQL2K8

arabiou — Mon, 28 Jan 2008 21:14:38 GMT

La vie

re: How We Developed SQL2K8

johnw — Tue, 29 Jan 2008 05:34:33 GMT

I have to say that this is somewhat disappointing to read. The timing of this post and the announcement of the SQL 2008 delay is no coincidence. On the one hand, I'm quite happy to see that it's delayed, and not being pushed out the door. On the other hand, long standing 'behavior by design' issues stand open, and carry forth to SQL 2008. For example, the performance of management studio is just not on par with what we had in SQL 2000 - and isn't materially better in SQL 2008!

re: How We Developed SQL2K8

ThomasL — Tue, 29 Jan 2008 19:52:58 GMT

Did we get Ctrl+B (to move the splitter bar) in the query-execution window?

re: How We Developed SQL2K8

dtjones — Tue, 29 Jan 2008 20:22:04 GMT

Ctrl-B is something we're still considering. You can track it here; http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=276081

re: How We Developed SQL2K8

Shan — Wed, 30 Jan 2008 05:10:59 GMT

Perhaps a more balanced approach would be more appreciated by customers. Deliver some of the features on a more regular basis through out-of-band delivery mechanisms and service packs. Appreciate that customers do not want to wait 3 years to have something fixed, and for many issues that may not make it in the next build, it might mean a 6 year wait. So, I would recommend an approach that would deliver more frequent releases to customers and using alternate delivery mechanisms. For example, perhaps some of the management tools could have been delivered as a side product to helping manage a SQL 2005 installation, while SQL 2008 focuses on some of the fundamental changes in the database interior.

re: How We Developed SQL2K8

dtjones — Wed, 30 Jan 2008 05:31:37 GMT

In SQL2K5 SP2 we fixed over 700 bugs. I hesitate to give this number but I think it's important to recognize that SPs are already being fully leveraged for getting fixes to customers as quickly as possible.

re: How We Developed SQL2K8

Steve Jones — Wed, 30 Jan 2008 20:38:44 GMT

Dan,

Thanks for the note and I can certainly understand you working on the big features. We certainly don't want to fall behind Oracle, but it is disheartening to not have a good focus on fixing the last product at the same time. It's not like you don't have the resources (http://www.microsoft.com/msft/earnings/FY08/earn_rel_q2_08.mspx).

I think the Resource governor and DMF is fantastic and you've done a great job. Kuds to the team. Haven't worked with Intellisense or DC enough, but they are good steps.

However, SP2 is broken. It has issues, some of which were addresses in cumulative releases, some not. SP3 needs to be released that rolls up changes.

SQL Server Shorts

SELECT IsUseless(blabber) from sys.innarwebs CROSS APPLY jmass(blog) — Wed, 30 Jan 2008 22:08:05 GMT

Dan Jones provides some interesting insight into the development process of SQL Server 2008. SQL Customer Advisory Team releases a partition management utility on CodePlex. The storage engine team con ...

re: How We Developed SQL2K8

Hagrin — Thu, 31 Jan 2008 07:23:48 GMT

I appreciate your transparency in letting us know the general track you took when building SQL 2008. Unlike some of the previous commenters, I do see the benefit of the strategy you took ... as long as your team does get around to fixing those critical issues that SQL 2005 admins and developers have.

Part of me wishes that Reporting Services was one of the "big topics", but I can't disagree with the areas you chose to develop first.

Good luck with the release.

re: How We Developed SQL2K8

Ian Ringrose — Thu, 31 Jan 2008 13:14:41 GMT

I have mostly worked for ISV in the past, as often the software has to work on both Oracle and SQL Server we can not make use of match that in not in Sql Server 2000 (as there is nothing to match it in oracle) therefore our customers have no reason to upgrade to later versions of SQL server. Hence Microsoft does not get the profit from the updates.

You could change this by adding a few features to Sql Server that better match Oracle and therefore give us a VERY good reason to only support the latest version of SqlServer.

• Being able to defer the checking of a constraint until the transaction commits. This makes writing data updating code so match easer can is already supported on oracle.

• Allowing ALL additions of Sql Server to use index views, otherwise we can not make use of them, as some of our customers will only use the low end additions (they don’t have match data).

• Letting a stored proc return DataReaders as output parms, so that calling the stored proc is more like calling a oracle stored proc.

• Provide support for sequences, so that key generation can be done in the same way as on Oracle.

• Making it as easy to write SQL that returns trees as it is Oracle, e.g. support “Connected By” etc as well as your more power system.

re: How We Developed SQL2K8

Paschal — Tue, 05 Feb 2008 17:18:36 GMT

Dan

Thanks for the info, but I am very frustrated with the lack of fixing issues in SQL 2008. One thing I was hoping is to get a better Management Studio. When you think about the SOHO market, Management Studio is a disappointing tool, almost useless. I miss SQL 2000 Enterprise Manager. I don't really bother with new shiny toys, I want like many basic features working well.

SQL 2008 look more like a big service pack rather than a new product. After all when you look at Visual Studio, they got it wrong with the 2005 version and they get it right with the 2008 version. So why not the same with SQL 2008?

re: How We Developed SQL2K8

Jared — Tue, 05 Feb 2008 18:39:51 GMT

Dan,

Thanks for the good post. I find it highly interesting to learn what goes on behind the scenes.

A note on your Oracle thoughts. I work on applications that use both MSSQL and Oracle. I prefer MSSQL, but Oracle does scale a little higher (in part, I attribute that to Oracle’s different locking & memory management model). We use Oracle purely for it’s scalability, and not for it’s manageability.

My questions are: What scalability and performance improvements are in line for the next release of SQL Server? (One MSSQL scalability feature we could use: Asynchronous triggers – this would specifically enhance some very high load situations where we don’t need triggers to synchronous). Also, any chance the next release will be focused on bug cleanup, polish, and performance & scalability improvements?

Thanks