New SQL Server 2008 T-SQL Features - It's the little things that are cool...
Sql Stuff - Katmai - Did you know? Inline variable initialization and Compound assignment
"In Sql 2008 (Katmai), a couple of the 'smaller' features that are currently in the latest CTP include inline variable initialization and compound assignment (something you App Dev folks have had for years). So, the following types of code now work in Sql 2008:
declare @d datetime = getdate(), @i int = 1, @s varchar(100) = 'test';
-- Show the values...
select @d, @i, @s
-- Increment i, append to s...
select @i += 1, @s += 'ing';
-- Show the new values...
select @i, @s;These operators also work inline with DML statements and columns...for example, a simple UPDATE statement in a table called 'testTable' with a column called 'testColumn' where you wanted to increment the value of testColumn by 1 could be:
update testTable set testColumn += 1;
..."
I've been looking for my "hook" for SQL Server 2008. That "thing" that gets me excited about a release, the developer related coolness factor... Yeah the new data types are neat and all that, but they are not that big a draw for me.
But the above information/changes to T-SQL? THAT's cool!
Inline initialization? Rock On! Incriminators? Cool! Compound assignments? Nice!
Sure these are little things, but added together mean allot (to me at least).
(Yeah, yeah, yeah... I KNOW I need a life... :)
Posts
3 comments:
T-SQL only just getting to this point in syntax now! :) All the more reason for me to continue to think that sensible, disciplined coding of stored procs in C# is the better way to go. Your developers only need to understand one language (C#) and one DB mechanism (ADO), rather than a second in both cases (i.e. T-SQL).
Most DBA's I know hate the idea of C# sprocs and try to get them banned organisationally. I put that down to them not being able to read C# and vet the sprocs.
cheers
This is indeed cool info as it will make the T-SQL easier to read. As for the CLR stuff, CLR has it's place. An all out replacement for stored procedures is not it. A DBA who wants to ban CLR procedures simply because they are CLR procedures does not understand what .NET can offer. Alternatively, a Developer who wants to strictly use CLR as opposed to T-SQL does not understand the benefits of T-SQL over .NET. T-SQL is not hard so the "they only have to learn one language" argument is hard for me to bite onto.
Personally, I'm not interested in hiring developers who think that one language can/should solve every problem.
C# sprocs, for better or worse, are often banned. Might be nice to know another way to skin that cat.
Post a Comment