Writing a basic Stored Procedure is not a difficult task. First lets take a look at our inline query…

Example 1

1
2
3
4
5
6
7
8
9
10
11

<cfquery name="addCheesesToFlavors" datasource="CheesyDB">
	INSERT INTO
		CheesesToFlavors
			(
			flavorId,
			cheeseId
			)
	VALUES
		<cfqueryparam value="#variables.flavorId#" cfsqltype="cf_sql_int" />,
		<cfqueryparam value="#variables.cheeseId#" cfsqltype="cf_sql_int" />
</cfquery>

In this simple INSERT statement we are inserting a new record into CheesesToFlavors. Note the use of CFQUERYPARAM (a tag that all ColdFusion developers should be using).

Writing A Stored Procedure

Now lets take the above query and convert it to a stored procedure. To add a new stored procedure browse to [your_database_engine] > CheesyDB > Programmability > Stored Procedures, then right click on “Stored Procedures” and select “New Stored Procedure…”. Now you are ready to write some code!

First we declare our Stored Procedure and our input variables…

Example 2a

1
2
3
4

CREATE  PROCEDURE uspAddCheesesToFlavors
	@cheeseId INT,
	@flavorId INT
AS

Line 1 declares that “this is a stored procedure named ‘uspAddCheesesToFlavors’” Lines 2 and 3 are the two input variables that the procedure expects, and the datatype expected is int. Lastly we have the AS keyword.

Next we insert the record into the database…

Example 2b

5
6
7
8
9
10
11
12
13

INSERT INTO
	CheesesToFlavors
		(
		flavorId,
		cheeseId
		)
SELECT
	@flavorId,
	@cheeseId

This simple INSERT statement is similar to one that you would find in your inline queries. On line 11 we’ve replaced the “VALUES” keyword found in our inline query with the “SELECT ” keyword. On lines 12 and 13 we output the same two variables that we declared at the top of the procedure.

Calling Your Stored Procedure

Example 3

1
2
3
4

<cfstoredproc procedure="uspAddCheesesToFlavors" datasource="CheesyDB">
	<cfprocparam type="in" cfsqltype="cf_sql_int" value="#variables.flavorId#" />
	<cfprocparam type="in" cfsqltype="cf_sql_int" value="#variables.cheeseId#" />
</cfstoredproc>

Yes it’s that easy. Specify your procedure name and datasource name in the CFSTOREDPROC tag, declare your input variables in CFPROCPARAM tags and you are all set. Note that your CFSTOREDPROC tags have to be in the same order as your variable declarations in order for your procedure to work as intended!

Many Cheeses, Many Flavors

Since we’re using our stored procedure to insert records into an intermediary table that joins Cheeses and Flavors we need to be mindful of duplicate records. If we attempt to insert a duplicate record into this table we will throw an error. We only have to add the code in example 2d to prevent our database from inserting duplicate records…

Example 2d

14
15
16
17
18
19
20
21
22
23
24

WHERE NOT EXISTS
	(
	SELECT
		flavorId,
		cheeseId
	FROM
		CheesesToFlavors
	WHERE
		flavorId = @flavorId
		AND cheeseId = @cheeseId
	)

For your cutting and pasting pleasure, here are all of the “Example 2″ code samples merged into one place…

Example 4

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

CREATE  PROCEDURE uspAddCheesesToFlavors
	@cheeseId INT,
	@flavorId INT
AS
INSERT INTO
	CheesesToFlavors
		(
		flavorId,
		cheeseId
		)
SELECT
	@flavorId,
	@cheeseId
WHERE NOT EXISTS
	(
	SELECT
		flavorId,
		cheeseId
	FROM
		CheesesToFlavors
	WHERE
		flavorId = @flavorId
		AND cheeseId = @cheeseId
	)

Booya!

First we’ll create the database…

Example 1a

1

CREATE DATABASE CheesyDB

…then we’ll create the Odors table…

Example 1b

1
2
3
4
5
6

CREATE TABLE Odors
	(
	odorId INT NOT NULL,
	name VARCHAR(50) NOT NULL,
	PRIMARY KEY (odorId)
	)

…lets also create a “Cheeses” table…

Example 1c

1
2
3
4
5
6
7
8

CREATE TABLE Cheeses
	(
	cheeseId INT NOT NULL,
	name VARCHAR(50) NOT NULL,
	odorId INT,
	PRIMARY KEY (cheeseId),
	CONSTRAINT fk_OdorsCheeses FOREIGN KEY (odorId) REFERENCES Odors(odorId)
	)

You should now have a new database named “CheesyDB” with two tables named “Cheeses” and “Odors”. We should also have a foreign key constraint named fk_OdorsCheeses that establishes a one-to-many relationship between Cheeses and Odors. Lets add a few more tables…

Example 1d

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

CREATE TABLE Flavors
	(
	flavorId INT NOT NULL,
	name VARCHAR(50) NOT NULL,
	PRIMARY KEY (flavorId)
	)
 
CREATE TABLE CheesesToFlavors
(
	cheeseId INT NOT NULL,
	flavorId INT NOT NULL,
 
	CONSTRAINT [PK_CheeseToFlavor] PRIMARY KEY CLUSTERED
	(
		cheeseId,
		flavorId
	),
	CONSTRAINT fk_Cheeses_CheesesToFlavors FOREIGN KEY (cheeseId)
		REFERENCES Cheeses(cheeseId),
	CONSTRAINT fk_Flavors_CheesesToFlavors FOREIGN KEY (flavorId)
		REFERENCES Flavors(flavorId)
)

Now we have a new table “Flavors” and an intermediary table named “CheesesToFlavors” for tracking our many-to-many relationship between Cheeses and Flavors. The code on lines 13-17 makes the data from both the cheeseId and flavorId columns the primary key, and the code on lines 18-21 defines the foreign key constraints of the table.

I’ll be referencing this database in a series of related SQL and ColdFusion posts over the coming weeks. Cheers!

At my current job I am the one who writes the SQL for the small and medium-sized ColdFusion & SQL Server-based systems that I develop. Up until the other day I used implicit inner joins and over-used subqueries to get the data that I wanted from a database. My code worked, but it was ugly.

Ah Ha!

My SQL deficiency became apparent as I was sharing some code with a comrade yesterday. I was informed that my code had an “implicitly defined SQL Join”, and was informed that this style of coding is both deprecated and bad form. I was writing my queries like this…

SELECT	c.cheeseId,
	c.name,
	o.name AS 'odorName'
FROM	Cheeses c, Odors o
WHERE	c.odorId = o.odorId

…but as it turns out I should be writing them like this…

SELECT	c.cheeseId,
	c.name,
	o.name AS 'odorName'
FROM	Cheeses c
INNER JOIN
	Odors o ON c.odorId = o.odorId

Both queries will return the same results, but the latter is well formed, and consistent with other join types that you may have in your application.

Once I understood that, a lightbulb appeared over my head. I kicked out a few more code samples to observe the results of left and right joins (a concept that I have been having problems grasping).

Left Joins In The House

SELECT	c.cheeseId,
	c.name,
	o.name AS 'odorName'
FROM	Cheeses c
LEFT JOIN
	Odors o ON c.odorId = o.odorId

The above SQL will return all cheeses and their associated odors. Cheeses that don’t have an odor will also be returned with a null value in the odorName column.

Right Joins In The House

SELECT	c.cheeseId,
	c.name,
	o.name AS 'odorName'
FROM	Cheeses c
RIGHT JOIN
	Odors o ON c.odorId = o.odorId

The above SQL will return all odors and the cheeses that they relate to. Odors that don’t link to an associated cheese will also be returned with a null value in the cheeseId and name columns.

It’s interesting how not understanding one bit of theory or syntax can act as a closed door in your mind that keeps you from understanding a whole world of knowledge. This is why I always maintain an open mind and take a bit of time each day to read other developer’s blogs.