Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
- Microsoft SQL Server Administration
Microsoft SQL Server Programming
- An Outline for Development
- Database Services
- Database Objects: Databases
- Database Objects: Tables
- Database Objects: Table Relationships
- Database Objects: Keys
- Database Objects: Constraints
- Database Objects: Data Types
- Database Objects: Views
- Database Objects: Stored Procedures
- Database Objects: Indexes
- Database Objects: User Defined Functions
- Database Objects: Triggers
- Database Design: Requirements, Entities, and Attributes
- Business Process Model Notation (BPMN) and the Data Professional
- Business Questions for Database Design, Part One
- Business Questions for Database Design, Part Two
- Database Design: Finalizing Requirements and Defining Relationships
- Database Design: Creating an Entity Relationship Diagram
- Database Design: The Logical ERD
- Database Design: Adjusting The Model
- Database Design: Normalizing the Model
- Creating The Physical Model
- Database Design: Changing Attributes to Columns
- Database Design: Creating The Physical Database
- Database Design Example: Curriculum Vitae
- The SQL Server Sample Databases
- The SQL Server Sample Databases: pubs
- The SQL Server Sample Databases: NorthWind
- The SQL Server Sample Databases: AdventureWorks
- The SQL Server Sample Databases: Adventureworks Derivatives
- UniversalDB: The Demo and Testing Database, Part 1
- UniversalDB: The Demo and Testing Database, Part 2
- UniversalDB: The Demo and Testing Database, Part 3
- UniversalDB: The Demo and Testing Database, Part 4
- Getting Started with Transact-SQL
- Transact-SQL: Data Definition Language (DDL) Basics
- Transact-SQL: Limiting Results
- Transact-SQL: More Operators
- Transact-SQL: Ordering and Aggregating Data
- Transact-SQL: Subqueries
- Transact-SQL: Joins
- Transact-SQL: Complex Joins - Building a View with Multiple JOINs
- Transact-SQL: Inserts, Updates, and Deletes
- An Introduction to the CLR in SQL Server 2005
- Design Elements Part 1: Programming Flow Overview, Code Format and Commenting your Code
- Design Elements Part 2: Controlling SQL's Scope
- Design Elements Part 3: Error Handling
- Design Elements Part 4: Variables
- Design Elements Part 5: Where Does The Code Live?
- Design Elements Part 6: Math Operators and Functions
- Design Elements Part 7: Statistical Functions
- Design Elements Part 8: Summarization Statistical Algorithms
- Design Elements Part 9:Representing Data with Statistical Algorithms
- Design Elements Part 10: Interpreting the Data—Regression
- Design Elements Part 11: String Manipulation
- Design Elements Part 12: Loops
- Design Elements Part 13: Recursion
- Design Elements Part 14: Arrays
- Design Elements Part 15: Event-Driven Programming Vs. Scheduled Processes
- Design Elements Part 16: Event-Driven Programming
- Design Elements Part 17: Program Flow
- Forming Queries Part 1: Design
- Forming Queries Part 2: Query Basics
- Forming Queries Part 3: Query Optimization
- Forming Queries Part 4: SET Options
- Forming Queries Part 5: Table Optimization Hints
- Using SQL Server Templates
- Transact-SQL Unit Testing
- Index Tuning Wizard
- Unicode and SQL Server
- SQL Server Development Tools
- The SQL Server Transact-SQL Debugger
- The Transact-SQL Debugger, Part 2
- Basic Troubleshooting for Transact-SQL Code
- An Introduction to Spatial Data in SQL Server 2008
- Performance Tuning
- Practical Applications
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
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:
- Understand the goal or problem as completely as possible
- Comment the process
- Code the comments
- 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: Name e-mail address City 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) AS BEGIN TRY INSERT INTO Customer.CustomerDemographics (Fname, Lname, Email, City, State) VALUES (@Fname, @Lname, @Email, @City, @State) END TRY BEGIN CATCH IF @@TRANCOUNT > 0 ROLLBACK TRAN SELECT ERROR_NUMBER() AS 'ErrorNumber' , ERROR_SEVERITY() AS 'ErrorSeverity' , ERROR_STATE()) AS 'ErrorState' , ERROR_PROCEDURE() AS 'ErrorProcedure' , ERROR_LINE()) AS 'ErrorLine' , ERROR_MESSAGE() AS 'ErrorMessage' END CATCH /* 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.