Elegant Code » SQL

Three Times the Fun

Jason Grundy — Thu, 01 Jan 2009 02:37:10 +0000

Jason again. Over the past week, while most people have been enjoying some hard earned time off, I’ve been working…a lot. Joining me in my efforts have been fellow Elegant Coder Chris and Priyesh.

The nature of the projects that we undertake here can make it difficult to apply some key development principles. A particularly large obstacle has proven to be multiple developer projects…or lack thereof. Please don’t lecture me on the evils of this approach as I know the price that we pay for our sins. In fact when I first came on board here some 16 months ago this was the first thing that I changed (where I could) and it has had a more significant impact on the quality of our software than anything else that we have done.

And this fact was underlined by what we have achieved during the past week. In terms of quality and quantity I have not seen such a high level of output for a significant period of time. We challenged and supported each other and we had a bunch of fun too. Thanks guys – you rock!

SQL Server 2008 RC0 is out

Chris Brandsma — Sat, 07 Jun 2008 20:03:08 +0000

http://blogs.technet.com/andrew/archive/2008/06/06/sql-server-2008-rc0.aspx

Good to see this started. I like that it is RC0 (RC-Zero) and not RC1.

Data Dude Extensibility – How IBM integrated DB2 into Visual Studio

David Starr — Fri, 06 Jun 2008 13:52:59 +0000

I am sitting in a room at Tech Ed 208 with about 15 people who got up early enough for this session. I am blown away there aren’t more people in here, but I guess the after-party at Universal Studios last night kept people in bed late this morning. This session is a joint presentation by Gert Drapers (the actual Data Dude) and Brent Gross the from IBM for the DB2 integration project team.

It is clear (and stated) that other RDBMS vendors will follow suit as MS has provided a fundamentally pluggable model for vendors to integrate their DBs into Visual Studio with a provider model. Can you smell Oracle, boys and girls? I can. Gert is being vague about who they are working with. MySQL will be cool.

There are several levels of extensibility:

DB Provider

This is the actual connectivity to your own RDBMS. This provider is responsible for talking to the VS model layer for the DB project and translating between your DB and the model.

VS Features

The ability to alter features in Visual Studio, like:

Refactorings available for a given provider.
Syntax highlighting
language formatting rules for reverse engineering operations

Static analysis rules for your particular SQL language

Yes, you get static analysis rules for TSQL. This is the death clock for select * from …
Static analysis in BD2 SQL may be different than that in MS TSQL
You can write your own static analysis rules in .Net by inheriting from the provided Rule class or *yeah* implementing an interface (are we hearing a theme out of MS?) I suppose if your company were anal enough, you could actually implement your proprietary naming convention rules as static analysis rules. Gert actually did this is an demo by writing a rule that checked column names to ensure they were in Pascal case. Neato. The funny part is when some of the developers in the room started telling him how his demo code could be refactored. Lol.

Model Extensibility

VS actually works against a model of the data store and lets the provider do the translation.
Using the model paradigm for DB development provides full round trip model to implementation support for any given DB.
Gert actually showed a little command line app that looked at a Northwind DB in Access and a different Northwind DB in SQL Server and compared them. There would be very different SQL syntaxes if we were simply comparing creation scripts. The DBs showed as the same. More accurately, the models checked as the same. Cool.
So, I could script the process of taking a DB2 database and migrating it to SQL Server, or visa versa, in this model paradigm.

This session signaled several things to me.

MS products really are being designed with extensibility and integration in mind. No really, this time.
The Data Dude model of working with databases has genuine merit. The days of SSMS (SQL Server Management Studio) and the Query Analyzer fan base are numbered. Treating DBAs as developers really is a better model.
Something different is occurring at MS with the changing of the guard.

SQL Parameter Sniffing and what to do about it

Chris Brandsma — Sat, 17 May 2008 16:53:50 +0000

Here was an interesting problem we ran into yesterday. We have about 50 people using a web site that I help build. All but one of them was logging in with no problems. But any time our “special” user logged in (lets call him John Doe) he would get a timeout.

That one left us scratching our heads. Luckily we have top notch security in place, so we were able to log in as him as well (without him knowing, and without knowing his password).

Hint: use forms authentication and write your own membership provider on a mirrored production site that no one outside of IT knows about.

When we log in as him we also get a timeout. OK, time to fire up SQL Server Query Profiler and see what is going on…which doesn’t take long. We see the query, a stored procedure really, taking +30 seconds to run. When we log in as a different user it takes less than one second. In fact we can log in as any other user and it takes less than one second.

Next step, dissect the query. We pull the query out of the stored proc (it isn’t that complicated of a query) and run it from Management Studio with John Doe’s info. ~1 second.

WHAT??!!!

My coworker did some web searching and stumbled on the answer (Google to the rescue, giving us answers even when we really don’t know the question): SQL Parameter Sniffing.

WHAT??!!!

The rundown is that when SQL Server compiles the query and creates the execution plan, if you pass parameters from the stored procedure call directly into the query, SQL Server will use the values passed in to “influence” the query plan. That can be a bad thing. Here is the Microsoft definition:

“Parameter sniffing” refers to a process whereby SQL Server’s execution environment “sniffs” the current parameter values during compilation or recompilation, and passes it along to the query optimizer so that they can be used to generate potentially faster query execution plans. The word “current” refers to the parameter values present in the statement call that caused a compilation or a recompilation.

Luckily the fix is easy. Take your stored procedure that looks like this (generalizing a query here:

CREATE PROCEDURE MyProcedure
    @UserName nvarchar(20)
AS
BEGIN
    -- Insert statements for procedure here
    SELECT DisplayName, FirstName, LastName 
    FROM dbo.User
    WHERE UserName = @UserName
END

And change it to this:

CREATE PROCEDURE MyProcedure
    @UserName nvarchar(20)
AS
BEGIN
    DECLARE @myUserName nvarchar(20)
    SET @myUserName = @UserName
    -- Insert statements for procedure here
    SELECT DisplayName, FirstName, LastName 
    FROM dbo.User
    WHERE UserName = @myUserName
END

Look on lines 5,6, and 10 for changes.

What did I really do? I once again proved that any programming problem can be solved with another layer of indirection. Really.

For some strange reason, when you pass the parameters (@UserName in this case) to a local variable (@myUserName) SQL Server will no longer use the value of the parameter (@UserName) to influence the query plan.

If you don’t believe me (and really, you shouldn’t ever believe the word of just one person), do a Google search on SQL Parameter Sniffing.

We tried it, tested it, did a performance check on it, it worked. But this now goes onto the top of my “Strange fixes for SQL Server” stack.

Other references:

SQL Ejaculation

David Starr — Sat, 22 Mar 2008 04:01:32 +0000

SQL Injection is the practice of slipping SQL code into a database execution command to get the DB to do something indirectly. Although this is a famous condition of a security vulnerability, it is less touted but more widely used by nefarious developers looking to subvert soul-crushing DBAs.

A typical example is the 1 month turnaround cycle for a new stored proc resulting in the inclusion by a developer of a "secret" stored proc that will execute whatever SQL sent to it as a string. I bring this up only because I know it is a less talked about, but very real.

The exact opposite of SQL Injection is (named by me) SQL Ejaculation. SQL Ejaculation is the practice of DBAs trying to insert their idea of view logic into an application via stored procedures.

Here is a classic example of SQL Ejaculation.

CREATE PROCEDURE sp_getCustomers
AS
SELECT "" + FirstName + "" + LastName + ""
FROM Customer

And before you even ask, yes, people really do this. In fact, when I learned how to do it 15 years ago or so, I thought it was kind of cool. We all grow wiser, right?

SQL Server 2008 Release "Revision"

David Starr — Fri, 22 Feb 2008 23:38:58 +0000

SQL Server 2008 won’t release with the other 2008 products in March as originally planned, according to this article. It would be easy to take a cheap shot at this, but I would instead like to applaud the company’s decision to wait until the dish is fully baked.

How many of us work in a time-boxed release schedule with no apparent logical reason given for shipping on a particular date? The fact that Microsoft is choosing to take the hit in revenue and reputation to deliver something better, but later, should give us all heart. In an industry where quality is often forsaken for time-to-market, I will take quality any day.

One of my favorite quotes on the subject (who said it, I don’t know) is, "Customers will forget that you delivered late. They will always remember that you delivered crap."