Wait, let’s back up:

Sweat mars your brow as you start to feel panic set in.  You reach for your mountain dew can and quickly put it down so no one will see your hand shaking (plus don’t want to spill a good dew).

Still need to back up further:

You were minding your own business watching a great SQLPASS webcast and thinking of how you were going to implement those cool things you learned.  At least, that was until you got THE PHONECALL.  Your boss calls and says, “Hey there’s this project going on that is going to need some database help, I’ve told them you’re just the person to do it.  So I’ve scheduled you in a conference call tomorrow morning first thing.  Sounded pretty straight forward so should be no problem.” You then start downloading your brain to notepad and internet links so you don’t forget the SQLPASS presentation.

You come in the next day, get your morning Mountain Dew (hey it’s my story and I’m not much of a coffee drinker) and jump on the conference call.    That is when you hear this:

“Glad you could join us; your boss said you were the best, so we’re expecting great things from you.  What we need is a database to store the Excel documents we’ve been working on for the past year.  We’ve just been emailing them around, so we’ll need to import the data and be able to create reports.  I already spec’d it out in Access and don’t think it should take more than a week, but with you on here, it should take less time!  This is good because we’re already committed to deadlines in about a month. I will email you the Excel documents, once you look and understand them we will talk later this afternoon to answer any questions you have. K, thanks, bye”

You start seeing visions of SSIS, SSRS and SQL go through your head and you’re wrapping your brain around everything that needs to be done, when you get the email: “Here’s a couple of the first type of spreadsheets, there are actually 3 different types of spreadsheets but it’s all related.  Should be no problem for a wiz like you, huh? When you’re ready for the rest, let us know and we can create a CD of them – think there’s about 300 or so.  I forgot to mention on the call that while we have a deadline in a month, we promised to start getting reports out next week, so I’m really looking forward to seeing the reports this week.”

Sweat mars your brow as you start to feel panic set in.  You reach for your mountain dew can and quickly put it down so no one will see your hand shaking (plus don’t want to spill a good dew).   Then a thought creeps into your head, you initially reject it, and look around to make sure no one heard it, but as you think about it, the thought starts making sense and you start to smile.  You now have the way to meet or possibly exceed the expectations and you can look like the hero.  So you say to yourself, “Don’t worry, I’ll just import manually, create the code as I go to be quick, then I can go back and clean it up later”

———————

The above scenario is not that uncommon in our field.  We are brought in as the experts and expected to produce things quickly.  The business group does not know and possibly does not even care about everything we do. But, really, it is not their job, if they did, you would not have one.  Things like code quality, code coverage, and security are your job, not theirs.

However, I am still seeing too many people try to be the hero by working around the clock or reducing code quality to meet the requirements as soon as possible.  Let me refute some more common reasons:

I will have plenty of time…

The idea that you will all of a sudden have this huge amount of free time to do performance improvements, proper error handling, better naming conventions, etc. is a myth.  More likely, you will be pulled onto another project and then someone will knock on your door in a year or two asking you to explain this really bad code they found.  If on the other hand you are experiencing large blocks of free time, please send me a note as I might have some work for you.  Companies pay you to work, which is the opposite of having free time.

I’ll just do it this once…

If you put that kind of code out there, you will probably end up doing a lot of manual process/manipulation.  This means when it is time to actually go-live, you scramble to get it all working, again reducing quality.  I have often seen “While it’s in development I don’t have to worry about getting it scheduled.  Oh that process didn’t work; I’ll just manually fix it.”  If you have to fix it manually in development, you will have to fix it manually in prod.

They just don’t understand

Our job should not just be seen as a cost center it should be seen as an asset.  That does not mean we just produce great code/functionality, it means we help the business achieve the business goals.  In other words, we work “with” not “for” the business. 

Back in the Exchange 5.5 days, I did some work as a systems administrator.  We discovered that some people were using mailboxes that had up to 500 MB in them, while the average was around 100; I researched best practices and did all this analysis.  I finally brought the suggestion to my boss, “We should limit everyone’s mailbox to XX size that way we don’t have space issues” His response “This is obviously the way our people work and if it is, why we shouldn’t just invest in more space so they can continue to work that way?” 

I had never considered the business, only the technology.  When you just have technology on the brain and not the business or the people you come up with solutions for the technology. “My system would be perfect except for all those users”

Take the time to explain what you need to accomplish so you can create what they want you to accomplish.  They want it sooner rather than later? Then reflect some of those decisions back to them, even empowering them to make some.  “Yes I can get that really cool function out there this week, but everyone in the world will have access to it,  With a couple more days I can also have it secure.  Which would you like?”  Of course, this means that you have to think more strategically about the project, which can be difficult at times.  We all know how easy (and fun) it is to just jump in there and start producing code”.  Transparency is the key.

But I’m always having to change things

Realize that some refactoring will always be necessary. The days of going away for 6 months to create something and come back to do your big “ta-da” are long gone.  People want things faster with more agility so things can change as we go along.    This means more pressure to produce faster, which means refactoring and adding additional functionality as you go.  However ever line of code you write should be quality.  I don’t know how many times I have seen Proof-of-Concepts (POCs) turn into the actual production system.  Just because it is a POC from a business perspective does not mean that it should be a POC from a code quality perspective.  I actually saw someone code up a textbook T-SQL injection (put the stored procedure parameter straight in the where clause without any validation), with the intention of fixing it later.  If it is wrong to do later, it is wrong to do now.

In the development world, there are many tools for code coverage, unit testing, refactoring, etc.  While there are some tools out there like VSDBPro unit testing, VSDBPro and Red Gate refactoring, etc., the tools in the database world are not as mature.  There is no IDE that forces white space or automatically documents for you.  We do not have tools where we can just do a few clicks and have end-to-end tests.

However, that is no excuse to be a gunslinger and just shoot from the hip.  We are professionals and should be creating professional code that is readable, documented and have a standard of quality.

If you are struggling with that, adopt a Test Driven Development (TDD) philosophy or something else that will force you to think about or do things better. 

Or maybe it is taking you 5 minutes to figure out what is going on in a stored procedure you just wrote a couple days ago.  If so, let’s be honest you failed in either code readability and/or documentation. No excuses, there are even good free tools out there. Whitespaceisreallyagoodthing.

Code Quality, Code Readability and Code Documentation is Important

I prefer to assign permissions to roles and add users to roles which mirrors the user/groups of windows, so going down that path we have to create a role (going under Security –> Roles):

CREATE ROLE [TestRole]

Now comes the part that isn’t very intuitive.  To associate a user with a role you have to go back to the Solution Explorer and actually create a generic user script file (see here), you can call it whatever you want and place it wherever you want in the project, however if you reverse engineer the database it will be called <ProjectName>.rolememberships.sql under the schema objects folder:

EXECUTE sp_addrolemember @rolename = N'TestRole', @membername = N'TestUser';

Now we have the role defined and the users as part of the role, we can start adding permissions, this is where you’ll have loads of fun provided you enjoy manually editing xml documents.  Again in Solution Explorer under Properties you’ll see a Database.sqlpermissions.sql file:

In there you’ll see some xml with examples:

<?xml version="1.0" encoding="utf-8"?>
<?XML:NAMESPACE PREFIX = [default] urn:Microsoft.VisualStudio.Data.Schema.Permissions NS = "urn:Microsoft.VisualStudio.Data.Schema.Permissions" />
  

So as you can see while it’s not that intuitive it is pretty straight forward.

So first we take the Server project and create the login for the user (if don’t know the difference between Logins and Users go read K. Brian Kelley’s post here, I’ll wait).  If you are in Schema view (and if not, why not?) make sure to go under Server Level Objects –> Security –> Logins, not the Security –> Users path, as you want a Server Login, not a master db User.

You’ll also notice in the Add new item dialog that there is a different template for each:

• Login (Windows Auth)
• Login (Sql Server)

At this point you might also be tempted in creation of the login to assign a default database, avoid that temptation.  When you assign a default database, that user database must already exist, however when you deploy the server project (i.e., the master database) there’s a good chance the user database won’t exist yet, I promise we’ll take care of it later though.

CREATE LOGIN TestLogin WITH PASSWORD = 'P@ssw0rd1'

So now that you have a server login in the server project we need to create a database user (remember to reference the server project in the database project).  This time you can go under the Security –> Users path.

CREATE USER [TestUser]
    FOR LOGIN [TestLogin]
    WITH DEFAULT_SCHEMA = dbo;

Now we have a login and a user created, lastly we set the default database in the database project post-Deployment script:

ALTER LOGIN [TestLogin] WITH DEFAULT_DATABASE=[$(DatabaseName)]

As you see I’m using the variable of the database name since I can change the database name for each deployment:

Taking a look at pertinent parts of the deployment sql scripts we have (remember this is in SQLCMD mode):

/*
Deployment script for master -LocalServer.sql
*/
:setvar DatabaseName "master"
GO
USE [$(DatabaseName)]
GO
PRINT N'Creating TestLogin...';
GO
CREATE LOGIN [TestLogin]
    WITH PASSWORD = N'P@ssw0rd1', DEFAULT_DATABASE = master;
GO
------------------------------
/*
Deployment script for AdventureWorks - AdventureWorks.sql
*/
:setvar DatabaseName "AdventureWorks"
GO
CREATE USER [TestUser] FOR LOGIN [TestLogin];
GO
ALTER LOGIN [TestLogin] WITH DEFAULT_DATABASE=[$(DatabaseName)]
GO

First I want to highlight the differences between Solution Explorer and Schema View.  Solution Explorer is the physical file structure, it doesn’t know about relationships other than the folder structure:

Then there is the schema view which does understand the relationships within the database and models very closely the Management Studio layout:

As you would imagine there are pros and cons to both.  For example if you have invalid syntax for defining a table, you won’t even see it in schema view, you’ll only see it in solution explorer.  However if you have a foreign key relationship that points to a missing column you’ll see it in schema view with the warning symbol.  Also the schema view has appropriate icons for different object types.

However back to the issue of schema management.  I’m very particular about naming conventions and file placement so not trusting the tool (sorry Gert) I figured I new better and would just go into solution explorer and create the new schema myself.  No problem:

And then I tried to create objects under that scheme however the folder structure wasn’t there!!  What a pain, so I went out to Windows Explorer copied the file structure from an existing schema, removing all the objects and added them into the project via Solution explorer, all the time wondering about the person who thought this was a good idea.

However lo and behold had I just switched over to schema view which understands what a schema is and what it can have, I would have been fine.

What’s more is that when I created my first table, it automatically not only created the table sql file, it created the entire folder structure, seen below back in solution explorer:

So while we’re all used to utilizing Solution Explorer for our projects, for Database projects please be aware and use Schema view unless you have to deal with the actual files themselves.

In Database Professional there is are two types of projects, the database project and the database server project.  The database project would be the user database while the database server project would be the master database.  Neither one is specific to a particular server or instance, it’s a Visual Studio project which can be deployed on a single or multiple instances as you need.

You can also create dependencies between projects so you can have a database project which had a dependency on a database server project.  Why would you do this you ask?  The most straight forward example would be the login to user relationship.  You could have a database server project which creates your logins, and a database project which then creates the users in that user database mapped back to the logins in the server project.

You can reference a database project one of three ways:

1. Project within the solution
2. .schema file (DB projects don’t create .dll files)
3. Server and database variables

The first two are pretty straight forward as you would just select a project or a .schema from your workspace, so let’s look at how you would utilize variables for reference.  First here’s the screen to create a dependency:

Easy enough, just enter the variables and you would have:

You’ll notice in the variables the characters %(), this is what tells the Project that these are variables, and I didn’t enter the variables this way, I just entered ServerName and when I tabbed out of the filed the $() were automatically added.  So now you can see the variables in your command variables dialog (under project properties).  The first two are created with every project and you’ll see since I specified a value up above, the value is already used, instead of needing to set it at deployment time.

So now that we have the variables, how does this actually get used when we go to deployment?  I’m glad you asked, on deployment a .sql file is created that utilized sqlcmd mode.  So the output at deployment time time will be:

Notice that there is no value for the DefaultDataPath, as I never did set it at deployment time.  So there you have it, you can now parameterize your project dependencies!