To kick off this blog, I am going to start with a topic that is hot on the mind of most developers who begin using databases in a serious way, and that is performance!
As developers begin using databases or scale up into applications that need to track a lot of data, performance issues (i.e. “This thing is slow” and “is the hourglass supposed to not go away like that?”) will creep in during database calls.
Here’s the backdrop: Development is done, the app is in the can, and it breezes through user acceptance. Now the roll out begins. Within a few days, you start hearing murmurs that parts of the app are slow. These murmurings soon become help tickets. These help tickets soon become meetings with the boss and the users. These meeting often turn into alcoholism…. You get the point.
Any application that deals with a lot of data has ample opportunities for poor performance. Often, developers are happy just to make the database access work and leave it at that. With some care, the database developer can prevent these problems in development. This series will cover the issues I see most SQL Server developers struggle with, particularly when they are new to the ever expanding world of SQL Server.