Top three "DUH" features of SQL 2008...

I'm very excited to get my hands dirty with SQL 2008.

Don't get me wrong, there is much to love with this current 2005 version, but some of these features I hear coming down the pipeline have me wondering why we didn't do things like this in the first place.

1. The MERGE command. Is this data a new row, or is it changes to an existing row? How many times do we write SaveOrUpdate(..) methods in our code with this "IF its new, insert it, otherwise update it" code? This line of thinking became a subconscious action, and we were used to writing this logic over and over. Merge allows you to synchronize two sets of data in an "en masse" approach. Suppose you have a dataset, xml, or some other input called "src" that is the data you want to merge into a table called "dest":
   

   MERGE dest USING src
   ON (src.key = dest.key)
   WHEN MATCHED THEN
     UPDATE [all dest values to update... regular update command here]
   WHEN NOT MATCHED THEN
     INSERT [a simple insert command from src to dest!]
   

   Cmon tell me that is not cool! You can wrap this in a transaction and a try..catch block to make it better. Duh! We needed this years ago!
   
2. Heirachical Data. Tree-structured data is a fact of life. When you need it , you need it, but SQL server support for this scenario has been very shaky in the past, and everyone needs to get creative to store trees in the relational database. Some ways are compliacted, some ways are non-performant, and all of them expose some ugly compromise. Finally, sql 2008 supports clustered indexing in a hierarchical fashion (breadth-first or depth-first ordering). Consider this table:
   

   CREATE TABLE ParentChildOrg
    (
     EmployeeID int PRIMARY KEY,
     ManagerId int REFERENCES ParentChildOrg(EmployeeID),
     EmployeeName nvarchar(50)
    ) ;
   GO
   

   Using this definition, here is some sample code from the docs that runs an optimized insert:
   

   DECLARE @Manager hierarchyid
   SELECT @Manager = CAST('/3/1/' AS hierarchyid)
   INSERT HumanResources.EmployeeDemo (OrgNode, LoginID, Title, HireDate)
   VALUES
   (@Manager.GetDescendant(NULL, NULL),
   'adventure-works\FirstNewEmployee', 'Application Intern', '3/11/07') ;
   

   Granted, I'm still trying to learn the good and bad things that come with the syntax of the hierarchyId data type, this is much needed support for sql server. Is there a need for native support for trees? duh!
   
3. Native file support for BLOBS. I have learned some serious hard lessons about this one in the past. You need to store blobs, if you store them directly in your database, then you are setting yourself up for a scalability nightmare scenario. If you are storing URLs to the blob data, then you need to manually synchronize your data with sql server. Finally, our 2008 version allows us to store blobs as an INTERNAL file structure to sql server, while exposing them as filestreams and not large unwieldy hunks of heavy data that wreak your I/O. We've all been treating sql server like a file server in the past, because we need it to serve files, not just chunks of data. DUH!

Its like a cell phone, or email... I mean, once you have it, you ponder how you ever got anything done without it, and those are the signs of Good ideas.