Home > Articles > Data > SQL Server

SQL Server Reference Guide

Hosted by

Toggle Open Guide Table of ContentsGuide Contents

Close Table of ContentsGuide Contents

Close Table of Contents

An Outline for Development

Last updated Mar 28, 2003.

I've covered quite a few syntax examples and algorithm explanations in articles on the specifics of Transact-SQL Code development. But syntax and algorithms aren't the complete picture; they are the tactics you use to implement a strategy, and that strategy is the process of development.

Perhaps you're a professional developer who has moved into the database administration or development role. Or, your team may already have a sophisticated development process. In those cases, you probably already have experience in developing code. There are several formal methods and processes for large-scale development efforts. These processes include things like a formal Application Lifecycle Management (ALM), working through Unified Markup Language (UML) diagrams and so on. Those decisions will largely be driven by your team or organization. Those are deep topics, and there are several references for them here at InformIT.

In this tutorial, I'll focus more on the specific process for writing Transact-SQL (T-SQL) code. This is a method I use whether I'm writing simple code for a view all the way to complex business logic within a stored procedure or other code. It's concise, easy to remember, and works well.

I break down the development task into four phases:

  1. Understand the goal or problem as completely as possible
  2. Comment the process
  3. Code the comments
  4. Optimize the code

Let's explore each of these in order. I'll refer back to these concepts in my future tutorials to create simple and more complicated programs.

Understand the Goal or Problem as Completely as Possible

In this phase, I try to gain an understanding of what is needed. Notice the two kinds of issues in this phase: the goal and the problem. A goal is long-term. In fact, the particular thing I am working on might only be a part of the solution. With a problem, I am often working on a smaller issue.

The key to this phase is a requirements document. This is a highly important instrument; it describes the goals and boundaries for the program. If you're paid for development work, it's also a legal contract. Without it, it's tempting for developers to think of one end result and the application's users to have another picture of the end result in their minds. You'll most likely have access to this document, since it's required to create a database in the first place.

Notice also that I seek to understand the issues as "completely as possible." The ideal process would involve being intimately familiar with the business process or scientific endeavor before the coding solution is framed. Often, in larger shops, a "Business Analyst" position is included on the development team to help with this process.

Unfortunately, time and resources don't often permit a complete understanding of the business or process. In this (unfortunately more common) case, it's important to do two things: create the requirements document in concert with the users, and have frequent reviews with the users to validate the program's design. Because the development staff (even or maybe especially if that's only you) doesn't have time to learn more about the business, the business users need to learn more about the development process. This can be painful, but it's necessary. To do so, I bring the business representative into the development design meetings, and include them in the process.

Just as an Entity Relationship Diagram (ERD) uses a simple set of symbols to quickly explain a database's objects and relationships, business process professionals also have a graphical language to describe processes. You can use standards such as Unified Modeling Language (UML), IDEFX0, or Business Process Modeling Notation (BPMN). I've used BPMN with some success, and I'll cover that topic in another article.

Once you have either a set of business requirements, a BPMN diagram or some other instrument to explain what the requirements for the program are, you can move on to the next step. A word of caution here — moving on without this information is a recipe for failure. In fact, there's an actual term for code that works correctly, but doesn't meet the need of the users due to poorly written or understood requirements: "Broken As Designed." Sad, but true. So take the time to get those requirements down before you begin coding.

Comment the Process

After the requirements have been laid out, the next step is to document the broad outline of the program. This outline serves as the overview for the program flow.

Take the main points from the business requirements and turn those into a general outline of what the code will do. For instance, here are a few items from a code request from a retail website. While the developers will code the HTML and other programming, the data professional pulls out the items that will become views, stored procedures and so on. I'll include only a few lines here to give you the idea of how to start the process. I put these right below the header of the T-SQL code.

Customer selects a product they are interested in from the website.
Customer input their name, e-mail address and select a city and state where they live.
Assign a salesperson to contact the customer, based on region.
E-mail the salesperson and the customer introducing each other.

You can use something as specific (or even more specific) than this, or make it more general to start. The point is to get something down that represents the programming objects you need.

At this point, the order of these items does not matter. That’s because you're working towards creating the programming objects like stored procedures or functions that add, delete or alter the data in the database. Those are called in turn by the higher-level web or other code in whatever order those programs run.

After the general requirements are annotated, you can refine the comments by breaking them out and adding details, changing the comments to be more specific, perhaps even specifying elements and types of logic like this:

/* Stored Procedure that updates customer data with: 
e-mail address
State */

/* Stored Procedure that assigns a salesperson to contact customer, looks up region and product choice. */

/* Function to e-mail the salesperson and the customer introducing each other. */

And so on. From here, take each of these comments and use the information from the database design and the business requirements to create the actual code.

Code the Comments

Now it's just a matter of applying two things to the comments: syntax and algorithms. In this part of the process, think about the program block and the best way to code it.

I'll continue on with the example to put everything into the final code snippet:

/* CreateWebPageInputScripts.sql
Purpose: Creates programming objects in the WebPage database.
Author: Buck Woody, 1/1/,2009
Last Edited: 2/3/2009
Instructions: Only run in a blank database. This is the creation script.
References: None.

Customer selects a product they are interested in from the website.
Assign a salesperson to contact the customer, based on region.
E-mail the salesperson and the customer introducing each other.

/* Stored Procedure that updates customer data with: Name, e-mail address, City
and State */
CREATE PROCEDURE usp_TakeCustomerInput
@Fname varchar(50)
, @Lname varchar(50)
, @Email varchar(100)
, @City varchar(100)
, @State char(2)
	INSERT INTO Customer.CustomerDemographics (Fname, Lname, Email, City, State)
	VALUES (@Fname, @Lname, @Email, @City, @State)
, ERROR_SEVERITY() AS 'ErrorSeverity'
, ERROR_STATE()) AS 'ErrorState'
, ERROR_PROCEDURE() AS 'ErrorProcedure'
, ERROR_LINE()) AS 'ErrorLine'
, ERROR_MESSAGE() AS 'ErrorMessage'
/* Other functions and code.... */
/* End CreateWebPageInputScripts.sql */

It's simply a process of building the script by working from the business requirements of what the database code needs through the comments, refining the comments, and then commenting the code. But you're not done just yet...

Optimize the Code

Next, optimize the code you just wrote. There are two schools of thought here. The first says to do this phase right after the code block is written, and the second says to wait until the whole program is complete.

The argument for the first method is that the code should be developed "properly" the first time — you shouldn't build bad code to begin with. The argument for the second method says that the whole body of code must be evaluated to find the best optimizations. Actually, either way works, so you should find a methodology that suits the way you work and make it a best practice.

There is certainly more to learn about working in a development environment, but these simple steps can help you start from the beginning, work through the middle, and stop at the end. Good advice given decades ago for writing, and it still works today for writing code.