Hey App, quit wasting my time sorting your data

An issue I run into quite a bit is unnecessary sorting in the database. I'm not talking about the sort of 'Get last 5' type of sorting where you need to sort to get a valid result set. I'm talking about the 'Hey Database! I want some data...and I'll probably throw some business logic in you... and while I'm here, how about we throw the presentation layer in as well and you sort the results for our UI!'

Nut Kicking:
In the same way that AppDevs outnumber DBAs, infrastructure wise there are typically way more web/caching servers than there are database servers. This is mostly due to the fact that like a decent DBA, a decent database server is expensive. AppDevsWebservers in general are cheaper, have less memory and don't need to be as awesome as a DBAdatabase server.

Code Please:
Lets take a look at some execution plans/cost so you can view 'ORDER BY' the same way I do.
Below is a simple example of selecting some badges by userid, and then display them alphabetically for the user to view :
SELECT Name
FROM dbo.Badges
WHERE userid = 91254;

SELECT Name
FROM dbo.Badges
WHERE userid = 91254
ORDER BY name DESC;

And this is the execution plan it creates:
execplan

On the bottom, do you see the glyph that is "Sort Cost: 15%"? As well as a difference of almost 10% in general between the two queries? Removing those "sort"(har har har) of thing adds up...like a lot.

Just Fix It
In C#, you have these things you can use called Ordered Enumerables and they are really easy to use... take a look:

public IOrderedEnumerable<dynamic> GetBadgeByUserId(int badgeid)
{
	var table = new Badges();
	var badges = table.query("SELECT  Name FROM dbo.Badges WHERE userid = @0", args: badgeid);
	return badges.OrderBy(x=>x.Name);
	//return badges.OrderByDescending(x => x.Name);
}

That wasn't too hard was it? In the above example, it is making a call to the DB (using Massive) and sucking the results into 'badges'. That is where it breaks off its relationship with the database, and sorts the results in 'badges' and returns them to whatever was calling it.

Does this make us happy?
I'm happy because you're not putting extra load on the DB. You're happy because you have some sorted data and can close a help ticket... everyone wins right?

But But But, our servers are busy too!
Ahhh, but perhaps you're one of those clever AppDevs who says that if the DB is getting over worked, then the webservers are too! Since I don't have the webserver metrics, I can't really object to that. But what I can say is: "Yo, that's cool. Since you are a programmer.... program up some javascript to sort the results in the UI. Then, the webservers and the db can both go listen to dub step or whatever servers like to do in their spare time."

There are a ton of ways to do this:
http://lmgtfy.com/?q=sort+a+table+with+jquery

Doing it on the front end also works great if you are stuck using some particular DALs or ORMs that take a bulimic approach to data retrieval IE - Eating everything in site and then barfing it out to the app.

GIT and Red Gate SQL Source Control

I am a huge fan of Red Gate SQL Source Control because it makes source controlling/deploying your database easier. I am aware of the MS Database Projects abomination application and the short version on that is that I have deemed them unworthy for my use. There are lots of tutorials and examples of using RG SSC with centralized version control systems like Subversion or TFS and it does work wonderfully with them. Recently, my workplace decided to ditch TFS and move to a more modern distributed version control named Git. Like most disruptions to your workflow, there are a few growing pains. This post is going to cover installing Git on Widows, hooking it up to github.com and showing some basic actions as we change our database.

Install Git:
Download the full installer for Git and install it.
While you are mindlessly clicking 'next' make sure you integrate with CMD. This is critical for RG SSC and just a convenient thing to do in general. The important part will look like this:
sourcecontrolcmd

Aside: I'm a converted fan of posh-git. Using things like the Git GUI or Tortoise GIT will be incredibly tempting, and perhaps for initial familiarization, it might be a good idea to use those to visualize some concepts. That being said, it is really in your best interest to move towards the CLI and posh-git is very helpful in that regard. It isn't nearly as bad as you think once you get going.

Repo Hosting
Once you have Git installed, you will want to hook up to some hosting. An incredibly popular and easy to use one is Github.com but there are plenty of others.

Repo Man
In Github, you will want to create your repository and assign your SSH keys. This process can be a bit more than you are used to at first, but GitHub as great at giving you some hand holding instructions: http://help.github.com/
Once the repo is initialized, I like to create a folder for the App and a folder for the database like so:
folder layout
You don't have to do it like that, but again, that is the way I currently like to do it.

Lets hook up the DB!
Why use the Adventure Works database? Since it is a bit of a marketing database used to show both neat and inane features, we're hooking it up just to make sure all types of various objects work just fine with RG SQL Source Control.
From there, go to SSMS and link up the DB to your local repository:
repo linko repo linko

Command Line Interface ... or whatever
Back in powershell (or whatever client you are using) create a new branch for updating our proc. git branch dbobjects
Note: We don't have to create a new branch. We could very easily just keep doing this in the 'master' branch. I find that creating of the branches to be a good habit and a handy organizational tool. Branching is one of those features that really shines in Git so lets put it to use.
Go into that branch: git checkout dbobjects
branchard

Now, we go back to SSMS and commit our changes:
no hands!

Cool! Our "dbobjects" branch has been committed locally, now we just need to merge it into our master branch!

From there, go back to master: git checkout master
and then merge into master our dbobjects branch: git merge master dbobjects
After we have merged, we can delete the branch we were working in by running:
git branch -d dbobjects
and the process will end up looking like this:
master merge

If you look on Github, you will see that nothing has changed there. Why is that? That is because all the work we have done has been locally. This is the essence and the speed of a distributed control system. We can commit, fix, break all we want without getting everyone else mad. However, at some point, we will need to send our changes off so that others on the team can use (laugh) at them. We do this by "push"ing to the origin: git push -u origin master
origin

Now, if we look at Github, we see our changes in the main repository, and if we go to check it out again:
yay

We can see them there for people pulling down changes. You've done it. Now you too can participate in the source control fun with the AppDevs and make nerdworthy comments about rebasing, merging and pushing master.

Oklahoma City JavaScript Group

A new user group is starting in Oklahoma City and it is one I find
completely fascinating... a Javascript group! With the monumental surge in popularity of Javascript over the past year or so, this type of group is a can't miss.

Who should attend you might ask? All of us in the tech field because it is pretty much everywhere now. Even a database douche bag like myself is attending because I have finally accepted that Javascript is inescapable. Javascript is all over the web, going to be all over the desktop with Windows 8, appearing in the mobile markets, and starting to take over the back end with rad technologies like NodeJS.

I'm a complete noob with Javascript and I feel completely comfortable coming to this group because with as fast as this technology is moving, we're all noobs and need to learn from each other. This group will not waste your time because

Learning is cumulative.

As a speed freak, my primary interest lies in NodeJS, but I know for a fact that I will learn something to help me with Node from Vance talking about BDD testing with a testing framework called Jasmine. That is just how it works. He gives, I take, and down the road I give back. Even if you don't know or care a thing about Javascript, it can be a good networking opportunity with some of the people in our community that have a true passion for tech and are trying to push tech boundaries. If that doesn't interest you, you can lurk in the back and watch me ask stupid questions as I try and get the info to the highly firewall'ed learning center that is my brain... or just show up for a free lunch. You have options.

If you don't go or don't plan to go...no worries. I'll still love you (as a friend), but in our very fluid industry, dropping an hour a month of your time on something like this is an incredibly way to not go stagnant.

The first meeting is January 24th from 11:30-12:30 at the OKC CoCo. Come say hi and most importantly.... help me learn this stuff!

For more information, hit up http://okcjs.com/