Shane Lively Michael Sarsany

SQL Server St andards
Version 1.5

I.

Naming Conventions

The m ain goal of adopt ing a nam ing convent ion for dat abase obj ect s is
so t hat you and ot hers can easily ident ify t he t ype and pur pose of all
obj ect s cont ained in t he dat abase. The inform at ion present ed here
serves as a guide for you t o follow when nam ing your dat abase
obj ect s. When reading t hese rules and guidelines, rem em ber
t hat consist ent nam ing can be t he m ost im port ant rule t o follow.
Please also keep in m ind t hat following t he guidelines as out lined in
t his docum ent can st ill produce long and crypt ic nam es, but will lim it
t heir num bers and im pact . However, ult im at ely your unique sit uat ion
will dict at e t he reasonabilit y of your nam ing convent ion. The goal of
t his part icular nam ing convent ion is t o produce pract ical, legible,
concise, unam biguous and consist ent nam es for your dat abase
obj ect s.
This sect ion is a generic DBMS- neut ral guide for nam ing com m on

obj ect s. While m ost dat abases cont ain m ore t ypes of obj ect s t han
t hose discussed here ( User Defined Types, Funct ions, Queries, et c.) ,
t he 7 t ypes of obj ect s m ent ioned here are com m on am ong all m aj or
dat abase syst em s.
The following t ypes of dat abase obj ect s are discussed here:
1.
2.
3.
4.
5.
6.
7.

Tables
Colum ns ( incl. Prim ary, Foreign and Com posit e Keys)
I ndexes
Const raint s
Views
St ored Procedures
Triggers

ALL D ATABASE OBJECTS
•
•

•

Try t o lim it t he nam e t o 50 charact ers ( short er is bet t er)
Avoid using underscores even if t he syst em allows it , except
where not ed in t his docum ent . PascalCase not at ion achieves t he
sam e word separat ion wit hout t hem and in fewer charact ers.
Use only let t ers or underscores ( t ry t o avoid num bers – and lim it
t he use of underscores t o m eet st andar ds for Const raint s,
Special- Purpose I ndexes and Triggers or unless im plem ent ing a
m odular nam ing convent ion as defined in t his docum ent ) .

Shane Lively & Michael Sarsany

Page 1 of 24

SQL Server St andards
Version 1.5
•
•
•
•
•

Use a let t er as t he first charact er of t he nam e. ( don't st art
nam es wit h underscores or num bers)
Lim it t he use of abbreviat ions ( can lead t o m isint erpret at ion of
nam es)
Lim it t he use of acr onym s ( som e acronym s have m ore t han one
m eaning e.g. " ASP" )
Make t he nam e readable ( t hey shouldn't sound funny when read
aloud) .
Avoid using spaces in nam es even if t he syst em allows it .

1 . TABLES
When nam ing your dat abase t ables, give considerat ion t o ot her st eps

in t he developm ent process. Keep in m ind you will m ost likely have
t o ut ilize t he nam es you give your t ables several t im es as part of ot her
obj ect s, for exam ple, procedures, t riggers or views m ay all cont ain
references t o t he t able nam e. You want t o keep t he nam e as sim ple
and short as possible. Som e syst em s enforce charact er lim it s on obj ect
nam es also.
Rule 1 a ( Singular Nam es) - Table nam es should be singular, for
exam ple, " Cust om er" inst ead of " Cust om ers" . This rule is
applicable because t ables are pat t erns for st oring an ent it y as a record
– t hey are analogous t o Classes serving up class inst ances. And if for
no ot her reason t han readabilit y, you avoid errors due t o t he
pluralizat ion of English nouns in t he process of dat abase developm ent .
For inst ance, act ivit y becom es act ivit ies, ox becom es oxen, person
becom es people or persons, alum nus becom es alum ni, while dat a
rem ains dat a.
Rule 1 b ( Prefixes) – Don’t use prefixes unless t hey are deem ed
necessary t o help you organize your t ables int o relat ed groups or
dist inguish t hem from ot her unrelat ed t ables. Generally speaking,
prefixes will cause you t o have t o t ype a lot of unnecessary charact ers.
Do not give your t able nam es prefixes like " t b" or " TBL_" as t hese are

redundant and wordy. I t w ill be obvious which nam es are t he t able
nam es in SQL st at em ent s because t hey will always be preceded by t he
FROM clause of t he SELECT st at em ent . I n addit ion, m any RDBMS
adm inist rat ive and/ or query t ools ( such as SQL Server Managem ent
St udio) visually separat e com m on dat abase obj ect s in t he
developm ent environm ent . Also not e t hat Rule 5a provides a m eans
t o dist inguish views from t ables.

Shane Lively & Michael Sarsany

Page 2 of 24

SQL Server St andards
Version 1.5
I n som e cases, your t ables m ight be sharing a schem a/ dat abase wit h
ot her t ables t hat ar e not relat ed in any way. I n t his case, it is
som et im es a good idea t o prefix your t able nam es wit h som e
charact ers t hat group your t ables t oget her. For exam ple, for a
healt hcare applicat ion you m ight give your t ables an " Hc" prefix so
t hat all of t he t ables for t hat applicat ion would appear in alphabet ized

list s t oget her. Not e t hat even for t he prefix, use PascalCase. This is
discussed in Rule 1c. Do not use underscores in your prefixes, which is
discussed in m ore dept h in Rule 1d. The last kind of prefix t hat is
accept able is one t hat allows you t o group logical unit s of t ables. A
plausible exam ple could ent ail a large applicat ion ( 30 t o 40+ t ables)
t hat handled bot h Payroll and Benefit s dat a. You could prefix t he
t ables dealing wit h payroll wit h a " Pay" or " Prl" prefix and give t he
t ables dealing wit h benefit s dat a a " Ben" or " Bft s" prefix. The goal of
bot h t his prefix and t he aforem ent ioned shared schem a/ dat abase
prefix is t o allow you t o group specific t ables t oget her alphabet ically in
list s and dist inguish t hem from unrelat ed t ables. Last ly, if a prefix is
used for t his purpose, t he shared schem a/ dat abase prefix is a higher
grouping level and com es first in t he nam e, for exam ple,
" HcPayClient s" not " PayHcClient s" .
Rule 1 c ( Not at ion) - For all part s of t he t able nam e, including
prefixes, use Pascal Case. Using t his not at ion w ill dist inguish your
t able nam es from SQL keywords ( cam elCase) . For exam ple, " select
Cust om erI d, Cust om erNam e from MyAppGroupTable where
Cust om erNam e = '% S'" shows t he not at ion for t he t able nam e
dist inguishing it from t he SQL keywords used in t he query. PascalCase

also reduces t he need for underscores t o visually separat e words in
nam es.
Rule 1 d ( Special Charact ers) - For t able nam es, underscores should
not be used. The underscore charact er has a place in ot her obj ect
nam es but , not for t ables. Using PascalCase for your t able nam e allows
for t he upper- case let t er t o denot e t he first let t er of a new word or
nam e. Thus t here is no need t o do so wit h an underscore charact er.
Do not use num bers in your t able nam es eit her. This usually point s t o
a poorly- designed dat a m odel or irregularly- part it ioned t ables. Do not
use spaces in your t able nam es eit her. While m ost dat abase syst em s
can handle nam es t hat include spaces, syst em s such as SQL Server
require you t o add bracket s around t he nam e when referencing it ( like
[ t able nam e] for exam ple) which goes against t he rule of keeping
t hings as short and sim ple as possible.

Shane Lively & Michael Sarsany

Page 3 of 24

SQL Server St andards

Version 1.5
Rule 1 e ( Abbreviat ions) - Avoid using abbreviat ions if possible. Use
" Account s" inst ead of " Acct s" and " Hours" inst ead of " Hrs" . Not
everyone will always agree wit h you on what your abbreviat ions st and
for - and - t his m akes it sim ple t o read and underst and for bot h
developers and non- developers. This rule can be relaxed in t he sake of
space const raint s for j unct ion t able nam es ( See Rule 1f) . Avoid using
acronym s as well. I f except ions t o t his rule are deem ed necessary,
ensure t hat t he sam e convent ion is followed by all proj ect m em bers.
Rule 1 f ( Junct ion a.k.a I nt ersect ion Tables) - Junct ion t ables, which
handle m any t o m any relat ionships, should be nam ed by
concat enat ing t he nam es of t he t ables t hat have a one t o m any
relat ionship wit h t he j unct ion t able. For exam ple, you m ight have
" Doct ors" and " Pat ient s" t ables. Since doct ors can have m any pat ient s
and pat ient s can have m any doct ors ( specialist s) you need a t able t o
hold t he dat a for t hose relat ionships in a j unct ion t able. This t able
should be nam ed Doct orPat ient " . Since t his convent ion can result in
lengt hy t able nam es, abbreviat ions som et im es m ay be used at your
discret ion.

2 . COLUM N S - ( incl. PRI MARY, FOREI GN, AND COMPOSI TE KEYS)
When nam ing your colum ns, keep in m ind t hat t hey are m em bers of
t he t able, so t hey do not need t he any m ent ion of t he t able nam e in
t he nam e. When writ ing a query against t he t able, you should be
prefixing t he field nam e wit h t he t able nam e or an alias anyway. Just
like wit h nam ing t ables, avoid using abbreviat ions, acronym s or special
charact ers. All colum n nam es should use PascalCase t o dist inguish
t hem from SQL keywords ( cam elCase) .
Rule 2 a ( I dent it y Prim ary Key Fields) - For fields t hat are t he prim ary
key for a t able and uniquely ident ify each record in t he t able, t he
nam e should sim ply be [ t ableNam e] + “ I d“ ( e.g.in a Cust om er t able,
t he prim ary key field would be “ Cust om erI d” . A prefix is added
m ainly because “ I d” is a keyword in SQL Server and we would have t o
wrap it in bracket s when referencing it in queries ot herwise. Though
Cust om erI d conveys no m ore inform at ion about t he field t han
Cust om er.I d and is a far wordier im plem ent at ion, it is st ill preferable
t o having t o t ype br acket s around “ I d” .
Rule 2 b ( Foreign Key Fields) - Foreign key fields should have t he
exact sam e nam e as t hey do in t he parent t able where t he field is t he
prim ary. For exam ple, in t he Cust om ers t able t he prim ary key field

m ight be " Cust om er I d" . I n an Orders t able where t he cust om er id is

Shane Lively & Michael Sarsany

Page 4 of 24

SQL Server St andards
Version 1.5
kept , it would also be " Cust om erI d" . There is one except ion t o t his
rule, which is when you have m ore t han one foreign key field per t able
referencing t he sam e prim ary key field in anot her t able. I n t his
sit uat ion, it m ight be helpful t o add a descript or before t he field nam e.
An exam ple of t his is if you had an Address t able. You m ight
have anot her t able wit h foreign key fields like Hom eAddressI d,
WorkAddressI d, MailingAddressI d, or ShippingAddressI d.
This rule com bined wit h rule 2a m akes for m uch m ore readable SQL:
... File inner j oin Dir ect ory on File.FileI D = Direct ory.FileI D ...
whereas t his has a lot of repeat ing and confusing inform at ion:
... File inner j oin Dir ect ory on File.FileI d_Pk = Direct ory.FileI d_Fk ...
Rule 2 c ( Com posit e Keys) - I f you have t ables wit h com posit e keys

( m ore t han one field m akes up t he unique value) , it ’s recom m ended
t hat a seeded ident it y colum n is creat ed t o use as t he prim ary key for
t he t able.
Rule 2 d ( Prefixes) - Do not prefix your fields w it h " fld_" or " Col_" as it
should be obvious in SQL st at em ent s w hich it em s are colum ns ( before
or aft er t he FROM clause) . Do not use a dat a t ype prefix for t he field
eit her, for exam ple, " I nt Cust om erI d" for a num eric t ype or " VcNam e"
for a varchar t ype. These “ clog up” our nam ing and add lit t le value;
m ost int eger fields can be easily ident ified as such and charact er fields
would have t o be checked for lengt h in t he Obj ect Browser anyway.
Rule 2 e ( Dat a Type- Specific Nam ing) - Bit fields should be given
affirm at ive boolean nam es like " I sDelet ed" , " HasPerm ission" , or
" I sValid" so t hat t he m eaning of t he dat a in t he field is not am biguous;
negat ive boolean nam es are harder t o read when checking values in TSQL because of double- negat ives ( e.g. “ Not I sNot Delet ed” ) . I f t he
field holds dat e and/ or t im e inform at ion, t he word " Dat e" or " Tim e"
should appear som ewhere in t he field nam e. I t is som et im es
appropriat e t o add t he unit of t im e t o t he field nam e also, especially if
t he field holds dat a like whole num bers ( " 3" or " 20" ) . Those fields
should be nam ed like " Runt im eHours" or " ScheduledMinut es" .
Rule 2 f ( Field Nam e Lengt h) – Field nam es should be no longer t han
50 charact ers and all should st rive for less lengt hy nam es if possible.
You should, however, not sacrifice readabilit y for brevit y and avoid
using abbreviat ions unless it is absolut ely necessary.

Shane Lively & Michael Sarsany

Page 5 of 24

SQL Server St andards
Version 1.5
Rule 2 g ( Special Charact ers) – Field nam es should cont ain only let t ers
and num bers. No special charact ers, underscores or spaces should be
used.

3 . I N D EXES
I ndexes will rem ain nam ed as t he SQL Server default , unless t he index
creat ed is for a special purpose. All pr im ary key fields and foreign key
fields will be indexed and nam ed in t he SQL Server default . Any ot her
index will be given a nam e indicat ing it ’s purpose.
Rule 3 a ( Nam ing Convent ion ) – I ndexes will rem ain nam ed as t he
SQL Server default , unless t he index creat ed is for a special purpose,
in which case t he nam ing convent ion for special- purpose indexes
follows t his st ruct ur e:
{ U/ N} I X_{ TableNam e} { SpecialPurpose}
where " U/ N" is for unique or non- unique and " I X_" m at ches t he default
prefix t hat SQL Server assigns indexes.
Rule 3 b ( Prefixes and Suffixes) - Avoid put t ing any prefix ot her t han
t hat specified in Rule 3a before your special- purpose indexes..

4 . CON STRAI N TS
Const raint s are at t he field/ colum n level so t he nam e of t he field t he
const raint is on should be used in t he nam e. The t ype of const raint
( Check, Referent ial I nt egrit y a.k.a Foreign Key, Prim ary Key, or
Unique) should be not ed also. Const raint s are also unique t o a
part icular t able and field com binat ion, so you should include t he t able
nam e also t o ensur e unique const raint nam es across your set of
dat abase t ables.
Rule 4 a ( Nam ing Convent ion) - The nam ing convent ion synt ax for
const raint s looks like t his:
{ const raint t ype} { t able nam e} _{ field nam e}
Exam ples:
1. PkProduct s_I d - prim ary key const raint on t he I d field of t he
Product s t able
2. FkOrders_Product I d - foreign key const raint on t he Product I d field
in t he Orders t able
3. CkCust om ers_Account RepI d - check const raint on t he Account RepI d

Shane Lively & Michael Sarsany

Page 6 of 24

SQL Server St andards
Version 1.5
field in t he Cust om ers t able
The reason underscores are used here wit h Pascal Case not at ion is so
t hat t he t able nam e and field nam e are clearly separat ed. Wit hout t he
underscore, it would becom e easy t o get confused about w here t he
t able nam e st ops and t he field nam e st art s.
Rule 4 b ( Prefixes) A t wo let t er prefix get s applied t o t he const raint
nam e depending on t he t ype
Prim ary Key: Pk
Foreign Key: Fk
Check: Ck
Unique: Un

5 . VI EW S
Views follow m any of t he sam e rules t hat apply t o nam ing t ables.
There are only t wo differences ( Rules 5a and 5b) . I f your view
com bines ent it ies wit h a j oin condit ion or where clause, be sure t o
com bine t he nam es of t he ent it ies t hat are j oined in t he nam e of your
view. This is discussed in m ore dept h in Rule 5b.
Rule 5 a ( Prefixes) - While it is point less t o prefix t ables, it can be
helpful for views. Pr efixing your views wit h " vw" is a helpful rem inder
t hat you're dealing wit h a view, and not a t able. What ever t ype of
prefix you choose t o apply, use at least 2 let t ers and not j ust " v"
because a prefix should use m ore t han one let t er or it s m eaning can
be am biguous.
Rule 5 b ( View Types) - Som e views are sim ply t abular
represent at ions of one or m ore t ables wit h a filt er applied or because
of securit y procedur es ( users given per m issions on views inst ead of
t he underlying t able( s) in som e cases) . Som e views are used t o
generat e report dat a wit h m ore specific values in t he WHERE clause.
Nam ing your views should be different depending on t he t ype or
purpose of t he view . For sim ple views t hat j ust j oin one or m ore t ables
wit h no select ion crit eria, com bine t he nam es of t he t ables j oined. For
exam ple, j oining t he " Cust om er" and " St at eAndProvince" t able t o
creat e a view of Cust om ers and t heir respect ive geographical dat a
should be given a nam e like " vwCust om erSt at eAndProvince" . Views
creat ed expressly for a report should have an addit ional prefix of
Report applied t o t hem , e.g. vwReport DivisionSalesFor2008.

Shane Lively & Michael Sarsany

Page 7 of 24

SQL Server St andards
Version 1.5

6 . STORED PROCED URES
Unlike a lot of t he ot her dat abase obj ect s discussed here, st ored
procedures are not logically t ied t o any t able or colum n. Typically
t hough, st ored procedures perform one or m ore com m on dat abase
act ivit ies ( Read, I nsert , Updat e, and/ or Delet e) on a t able, or anot her
act ion of som e kind. Since st ored procedures always perform som e
t ype of operat ion, it m akes sense t o use a nam e t hat describes t he
operat ion t hey perform . Use a verb t o describe t he t ype of operat ion,
followed by t he t able( s) t he operat ions occur on.
Rule 6 a ( Prefixes or Suffixes ) - The way you nam e your st ored
procedures depends on how you want t o group t hem wit hin a list ing. I t
is recom m ended t hat you have your procedures ordered by t he
t able/ business ent it y t hey perform a dat abase operat ion on, and
adding t he dat abase act ivit y " Get , Save, or Delet e" as a suffix, e.g.,
( " Product I nfoGet " or " OrdersSave" ) or ( " spProduct I nfoGet " or
" spOrdersSave" ) .
I f your procedure ret urns a scalar value, or perform s an operat ion like
validat ion, you should use t he verb and noun com binat ion. For
exam ple, " Validat eLogin" .
The use of t he “ sp” prefix is accept able and encouraged. This will help
developers ident ify st ored procedures and different iat e t hem from
ot her non prefixed obj ect s such as t ables when viewing a list ing of
dat abase obj ect s.
Rule 6 b ( Grouping Prefixes) - I f you have m any st ored procedures,
you m ight want t o consider using a grouping prefix t hat can be used t o
ident ify which par t s of an applicat ion t he st ored procedure is used by.
For exam ple, a " Pr l" prefix for Payroll relat ed procedures or a " Hr"
prefix for Hum an Resources relat ed procedures can be helpful. This
prefix would com e before t he t able/ business ent it y prefix ( See Rule
6a) . Please not e t hat t his should be avoided unless absolut ely
necessary.
Rule 6 c ( Bad Prefixes) - Do not prefix your st ored procedures wit h
som et hing t hat will cause t he syst em t o t hink it is a syst em procedure.
For exam ple, in SQL Server, if you st ar t a procedure wit h " sp_" , " xp_"
or " dt _" it will cause SQL Server t o check t he m ast er dat abase for t his
procedure first , causing a perform ance hit . Spend a lit t le t im e
researching if any of t he prefixes you ar e t hink ing of using are known
by t he syst em and avoid using t hem if t hey are.

Shane Lively & Michael Sarsany

Page 8 of 24

SQL Server St andards
Version 1.5

7 . FUN CTI ON S
Funct ions follow m any of t he sam e rules t hat apply t o nam ing st ored
procedures. There are only t wo differences ( Rules 5a and 5b) t hat
exist so t he user of t he funct ion k nows t hey are dealing wit h a funct ion
and not a st ored pr ocedure and all of t he det ails t hat involves ( value
ret urned, can be used in a select st at em ent , et c.) .
Rule 7 a ( Prefixes) - While it is m akes lit t le sense t o prefix st ored
procedures, it is necessary t o dist inguish funct ions from st ored
procedures. To t hat end, you should prefix your funct ions wit h " fn" as
a helpful rem inder t hat you're dealing wit h a funct ion, and not a st ored
procedure.
Rule 7 b ( Funct ion Purpose ) – Funct ions should be nam ed as a verb,
because t hey will always ret urn a value ( e.g. “ fnGet OpenDat e” ,
“ fnParseTableToSt ring” , “ fnForm at Zip” , et c.) .
Rule 7c ( Funct ion Suffix) – Scalar funct ions do not need a suffix, but
t able- valued funct ions should indicat e t hat t hey ret urn a t able by using
a “ Table” suffix.

8 . TRI GGERS
Triggers have m any t hings in com m on wit h st ored procedures.
However, t riggers are different t han st ored procedures in t wo
im port ant ways. Fir st , t r iggers don't exist on t heir own. They are
dependent upon a t able. So it is wise t o include t he nam e of t his t able
in t he t rigger nam e. Second, t r iggers can only execut e when an I nsert ,
Updat e, or Delet e happens on one or m ore of t he records in t he t able.
So it also m akes sense t o include t he t ype of act ion t hat w ill cause t he
t rigger t o execut e.
Rule 8 a ( Prefixes) - To dist inguish t riggers from ot her dat abase
obj ect s, it is helpful t o add " t r" as a prefix, e.g. “ t r_Product sI ns” . As
long as you include t he t able nam e, t he operat ion t hat execut es t he
t rigger ( I ns, Upd, or Del) and t he " t r" pr efix, it should be obvious t o
som eone working wit h t he dat abase what kind of obj ect it is. As w it h
all convent ions you use, pick one and r em ain consist ent .
Rule 8 b ( Mult iple Operat ions) - I f a t rigger handles m ore t han one
operat ion ( bot h I NSERT and UPDATE for exam ple) t hen include bot h
operat ion abbreviat ions in your nam e. For exam ple,
" t rProduct sI nsUpd" or " t rProduct sUpdDel"

Shane Lively & Michael Sarsany

Page 9 of 24

SQL Server St andards
Version 1.5
Rule 8 c ( Mult iple Triggers) - Som e syst em s allow m ult iple t riggers per
operat ion per t able. I n t his case, you should m ake sure t he nam es of
t hese t riggers are easy t o dist inguish bet ween, e.g.
" t rUsers_Validat eEm ailAddress_I ns" and
" t rUsers_MakeAct ionEnt ries_I ns" .

9 . Use r - D efin ed D a t a Type s
User- defined dat a t ypes should be avoided whenever possible. They
are an added processing overhead whose funct ionalit y could t ypically
be accom plished m ore efficient ly wit h sim ple dat a t ype variables, t able
variables, or t em porary t ables.
Rule 9 a ( Prefixes and Suffixes) - To dist inguish a user- defined dat a
t ype from ot her dat abase obj ect s, it is helpful t o add " ud" as a prefix.
Rule 9 b ( Special Charact ers) – User- defined dat a t ype nam es should
cont ain only let t ers, num bers and underscores. No special charact ers
or spaces should be used.

1 0 . Va r iables
I n addit ion t o t he general nam ing st andards regarding no special
charact ers, no spaces, and lim it ed use of abbreviat ions and acronym s,
com m on sense should prevail in nam ing variables; variable nam es
should be m eaningful and nat ural.
Rule 1 0 a ( Nam e lengt h lim it ) – Variable nam es should describe it s
purpose and not exceed 50 charact ers in lengt h.
Rule 1 0 b ( Prefix) – All variables m ust begin wit h t he “ @” sym bol. Do
NOT user “ @@” t o prefix a variable as t his signifies a SQL Server
syst em global var iable and w ill affect perform ance.
Rule 1 0 c ( Case) – All variables should be writ t en in cam elCase, e.g.
“ @first Nam e” or “ @cit y” or “ @sit eI d” .
Rule 1 0 d ( Special Charact ers) – Variable nam es should cont ain only
let t ers and num bers. No special charact ers or spaces should be used.

1 1 . Usin g M odula r Pr e fix e s
When t he scope of t he dat abase is expect ed t o be ent erprise level or
scalabilit y is a great concern consider using a m odular obj ect nam ing
convent ion for prim ary dat abase obj ect s such as st ored procedures

Shane Lively & Michael Sarsany

Page 10 of 24

SQL Server St andards
Version 1.5
and views. This m et hodology involves ident ifying prim ary m odules of
t he syst em and assigning each of t hose m odules a prefix. When t hese
prefixes are applied t o t he nam es of dat abase obj ect s t his allows us t o
easily locat e m odule specific procedures and dat abase obj ect s for
easier m odificat ion and debugging.
Ex a m ple 1 :
We have a m odular syst em t hat deals w it h st udent s and t eacher dat a
separat ely. We have defined t hese m odules as such:
M odule N a m e
St udent
Teacher

Pr e fix
STU
TEA

As we im plem ent nam ing convent ions for our new obj ect s processing
specific t o each m odule we creat e an easier way t o find and view
m odule specific funct ionalit y.
spSTU_At t endance_I nserUpdat e
spTEA_Credent ials_Delet e
spSTU_Validat eSt udent I D
spTEA_Address_I nsert Updat e
spSTU_Address_I nsert Updat e
vwSTU_AllSt udent s
Ex a m ple 2 :
Should you find t he need for even m ore granularit y when
im plem ent ing your nam ing convent ions, consider using sub- m odules
as well.
M odule N a m e
Report ing
Dat a Collect ion

Pr e fix
RPT
DTA

Sub M odule N a m e
St udent
Teacher

Pr e fix
STU
TEA

spDTA_STU_At t endance_I nserUpdat e
spDTA_TEA_Credent ials_Delet e
vwRPT_STU_St udent Achievem ent Report
spRPT_TEA_TeacherQualificat ionsReport

Shane Lively & Michael Sarsany

Page 11 of 24

SQL Server St andards
Version 1.5
spDTA_STU_Address_I nsert Updat e
vwDTA_STU_Validat eSt udent

II.

Coding Conventions

1 . SQL St a t em en t s ( Se le ct s)
Use t he m ore readable ANSI - St andard Join clauses ( SQL- 92 synt ax)
inst ead of t he old st yle j oins ( SQL- 89 synt ax) . The older synt ax ( in
which t he WHERE clause handles bot h t he j oin condit ion and filt ering
dat a) is being phased out SQL Server 2005 and higher versions. This
“old st yle ” w a y of j oining t a ble s w ill N OT be suppor t e d in
fut ur e ve r sions of SQL Se r ve r .
The first of t he following t wo queries shows t he old st yle j oin, while t he
second one shows t he new ANSI j oin synt ax:
SELECT
a.AuthorId,
t.Title
FROM Titles t, Authors a, TitleAuthor ta
WHERE
a.AuthorId = ta.AuthorId AND
ta.TitleId = t. TitleId AND
t.Title LIKE '%Computer%'
SELECT
a.AuthorId,
t.Title
FROM dbo.Authors a
INNER JOIN dbo.TitleAuthor ta ON
a.AuthorId = ta.AuthorId
INNER JOIN dbo.Titles t ON
ta.TitleId = t.TitleId
WHERE
t.Title LIKE '%Computer%'

Do not use t he “ Select * ” convent ion w hen gat hering result s from a
perm anent t able, inst ead specify t he field nam es and bring back only
t hose fields you need; t his opt im izes query perform ance and
elim inat es t he possibilit y of unexpect ed result s when fields are added
t o a t able.
Prefix all t able nam e wit h t he t able owner ( in m ost cases “ dbo.” ) . This
result s in a perform ance gain as t he opt im izer does not have t o
perform a lookup on execut ion as well as m inim izing am biguit ies in
your T- SQL.

Shane Lively & Michael Sarsany

Page 12 of 24

SQL Server St andards
Version 1.5
Use aliases for your t able nam es in m ost T- SQL st at em ent s; a useful
convent ion is t o m ake t he alias out of t he first or first t wo let t ers of
each capit alized t able nam e, e.g. “ Sit e” becom es “ s” and “ Sit eType”
becom es “ st ” .

2 . SQL St a t em en t s ( I n se r t s)
Always use a colum n list in your I NSERT st at em ent s. This helps in
avoiding problem s when t he t able st ruct ure changes ( like adding or
dropping a colum n) . Here's an exam ple t hat shows t he problem .
Consider t he following t able:
CREATE TABLE EuropeanCountries
(
CountryID int PRIMARY KEY,
CountryName varchar(25)
)

Here's an I NSERT st at em ent wit hout a colum n list , t hat works
perfect ly:
INSERT INTO EuropeanCountries
SELECT 1, 'Ireland'

Now, let 's add a new colum n t o t his t able:
ALTER TABLE EuropeanCountries
ADD EuroSupport bit

Now if you run t he above I NSERT st at em ent . You get t he following
error from SQL Server:
Server: Msg 213, Level 16, State 4, Line 1
Insert Error: Column name or number of supplied values does not
match table definition.

This problem can be avoided by writ ing an I NSERT st at em ent wit h a
colum n list as shown below:
INSERT INTO EuropeanCountries
(CountryID, CountryName)
SELECT 1, 'England'

3 . SQL St a t em en t s ( Form a t t in g)
SQL st at em ent s should be arranged in an easy- t o- read m anner. When
st at em ent s are writ t en all t o one line or not broken int o sm aller easy-

Shane Lively & Michael Sarsany

Page 13 of 24

SQL Server St andards
Version 1.5
t o- read chunk s, m ore com plicat ed st at em ent s are very hard t o
decipher. By doing t his and aliasing t able nam es when possible, you
will m ake colum n addit ions and m aint enance of queries m uch easier.
Refer t o t he exam ples below.
Confusing SQL:
SELECT dbo.DealUnitInvoice.DealUnitInvoiceID,
dbo.DealUnitInvoice.UnitInventoryID, dbo.UnitInventory.UnitID,
dbo.UnitInventory.StockNumber AS [Stock Number], dbo.UnitType.UnitType
AS [Unit Type], ISNULL(dbo.Make.Description, '') AS Make,
ISNULL(dbo.Model.Description, '') AS Model, DATEPART(YEAR,
dbo.Unit.ProductionYear) AS [Year], dbo.UnitType.UnitTypeID,
dbo.MeterType.Description AS MeterType, dbo.UnitInventory.MeterReading,
dbo.UnitInventory.ECMReading, '$' + LTRIM(CONVERT(nvarchar(18),
CAST(dbo.DealUnitInvoice.Price AS decimal(18, 2)))) AS Price, '$' +
LTRIM(CONVERT(nvarchar(18), CAST(dbo.DealUnitInvoice.Cost AS
decimal(18, 2))))
AS Cost, dbo.DealUnitInvoice.IsTradeIn, ISNULL(dbo.Unit.Vin, '') AS
Vin, ISNULL(dbo.Unit.SerialNumber, '') AS SerialNumber,
dbo.UnitInventory.AvailabilityStatusID,
dbo.UnitInventory.SellingStatusID, dbo.UnitInventory.IsNew,
dbo.UnitInventory.UnitPurchaseOrderID,
dbo.UnitInventory.BaseCost, dbo.DealUnitInvoice.DealPacketInvoiceID
FROM dbo.DealUnitInvoice INNER JOIN
dbo.UnitInventory ON dbo.DealUnitInvoice.UnitInventoryID =
dbo.UnitInventory.UnitInventoryID INNER JOIN
dbo.Unit ON dbo.UnitInventory.UnitID = dbo.Unit.UnitID LEFT OUTER JOIN
dbo.MeterType ON dbo.Unit.MeterTypeID = dbo.MeterType.MeterTypeID LEFT
OUTER JOIN
dbo.UnitType ON dbo.UnitInventory.UnitTypeID = dbo.UnitType.UnitTypeID
AND dbo.UnitType.InActive = 0 LEFT OUTER JOIN
dbo.Make ON dbo.Unit.MakeID = dbo.Make.MakeID AND dbo.Make.Inactive = 0
LEFT OUTER JOIN dbo.Model ON dbo.Unit.ModelID = dbo.Model.ModelID AND
dbo.Model.InActive = 0

Now look at t he sam e SQL St at em ent but organized in an easy t o read
and m ore m aint ainable form at :
SELECT
dui.DealUnitInvoiceID,
dui.UnitInventoryID,
ui.UnitID,
ui.StockNumber [Stock Number],
ut.UnitType AS [Unit Type],
COALESCE(mk.Description, '') Make,
COALESCE(ml.Description, '') Model,
DATEPART(YEAR,u.ProductionYear) [Year],
ut.UnitTypeID,
mt.Description AS MeterType,
ui.MeterReading,
ui.ECMReading,

Shane Lively & Michael Sarsany

Page 14 of 24

SQL Server St andards
Version 1.5
'$' + LTRIM(CONVERT(nvarchar(18),CONVERT(decimal(18, 2),dui.Price)))
Price,
'$' + LTRIM(CONVERT(nvarchar(18),CONVERT(decimal(18, 2),dui.Cost)))
Cost,
dui.IsTradeIn,
COALESCE(u.Vin,'') Vin,
COALESCE(u.SerialNumber,'') SerialNumber,
ui.AvailabilityStatusID,
ui.SellingStatusID,
ui.IsNew,
ui.UnitPurchaseOrderID,
ui.BaseCost,
dui.DealPacketInvoiceID
FROM
dbo.DealUnitInvoice dui
INNER JOIN dbo.UnitInventory ui
ON dui.UnitInventoryID = ui.UnitInventoryID
INNER JOIN dbo.Unit u ON
ON ui.UnitID = u.UnitID
LEFT JOIN dbo.MeterType mt
ON u.MeterTypeID = mt.MeterTypeID
LEFT JOIN dbo.UnitType ut
ON ui.UnitTypeID = ut.UnitTypeID
AND ut.InActive = 0
LEFT JOIN dbo.Make mk
ON u.MakeID = mk.MakeID
AND mk.Inactive = 0
LEFT JOIN dbo.Model ml
ON u.ModelID = ml.ModelID
AND ml.InActive = 0

Not e how t he t ables are aliased and j oins are clearly laid out in an
organized m anner.

4 . Se t t in g t h e N OCOUN T Opt ion
Use SET NOCOUNT ON at t he beginning of your SQL bat ches, st ored
procedures for report out put and t riggers in product ion env ironm ent s,
as t his suppresses m essages like '( 1 row( s) affect ed) ' aft er execut ing
I NSERT, UPDATE, DELETE and SELECT st at em ent s. This im proves t he
perform ance of st ored procedures by reducing net work t raffic.
SET NOCOUNT ON is a procedural level inst ruct ions and as such t here
is no need t o include a corresponding SET NOCOUNT OFF com m and as
t he last st at em ent in t he bat ch. Refer t o t he exam ple below.
CREATE PROCEDURE dbo.spDoStuff AS
SET NOCOUNT ON
SELECT * FROM MyTable
INSERT INTO MyTable(Col1,Col2,Col3)
SELECT ‘One’,’Two’,’Three’

Shane Lively & Michael Sarsany

Page 15 of 24

SQL Server St andards
Version 1.5
DELETE FROM MyTable
GO

5 . Code Com m en t in g
I m port ant code blocks wit hin st ored procedures and user defined
funct ions should be com m ent ed. Brief funct ionalit y descript ions should
be included where im port ant or com plicat ed processing is t aking place.
St ored procedures and funct ions should include at a m inim um a
header com m ent wit h a br ief overview of t he bat ches funct ionalit y.
Com m ent synt ax:
-- single line comment use 2 dashes (--)
/*
block comments use ( /* ) to begin
and ( */ ) to close
*/

Block com m ent s are preferred t o single line com m ent s ( even for
com m ent ing a single line) as cut and past e operat ions m ay dislocat e
t he double- dash single line com m ent , whereas t he block com m ent s
can never be dislocat ed.

6 . Usin g Code H ea de r s
St ored procedures, t riggers and user- defined funct ions should have a
code header. The header can be creat ed using t he com m ent synt ax
above. This header should give a br ief descript ion of t he funct ionalit y
of t he procedure as well as any special execut ion inst ruct ions. Also
cont ained in t his header t here should be a brief definit ion of any
param et ers used. Refer t o t he exam ple below. You m ay also include an
execut ion exam ple of t he funct ion or pr ocedure in t he header as well.
CREATE PROCEDURE [dbo].[spGBL_ValidateConcurrency]
@TableName varchar(255),
@ID int,
@LastUpdate datetime,
@IsValid bit OUTPUT
AS
/*********************************************************
This procedure validates the concurrency of a record update by taking
the LastUpdate date passed in and checking it against the current
LastUpdate date of the record. If they do NOT match the record is not
updated because someone has updated the record out from under
the user.

Shane Lively & Michael Sarsany

Page 16 of 24

SQL Server St andards
Version 1.5
--------------------------------Parameter Definition:
--------------------------------@TableName = Table to be validated.
@ID = Record ID of the current record to be validated.
@LastUpdate = The Last Update Date passed by app to compare with
current date value for the record.
@IsValid = Returns the following back to the calling app.
1 = Record is valid. No concurrancy issues.
0 = Record is NOT concurrent.
*********************************************************/

7 . Unicode vs. N on - Unicode D a t a Type s
Use Unicode dat a t y pes, like NCHAR, NVARCHAR, or NTEXT, ONLY if
your dat abase is going t o st ore not j ust plain English charact ers, but a
variet y of charact er s used all over t he world. Use t hese dat a t y pes
only when t hey are absolut ely needed as t hey use t w ice as m uch
space as non- Unicode dat a t ypes.

8 . CH AR vs. VARCH AR D a t a Type s
Use t he CHAR dat a t ype for a colum n only when t he colum n is nonnullable. I f a CHAR colum n is nullable, it is t reat ed as a fixed lengt h
colum n in SQL Server 7.0+ . So, a CHAR( 100) , when NULL, will eat up
100 byt es, result ing in space wast age. So, use VARCHAR( 100) in t his
sit uat ion. Of course, variable lengt h colum ns do have a very lit t le
processing overhead over fixed lengt h colum ns. Carefully choose
bet ween CHAR and VARCHAR depending up on t he lengt h of t he dat a
you are going t o st ore.

9 . Ve ry La r ge St r ings
I f you don't have t o st ore m ore t han 8KB of t ext , use CHAR( 8000) or
VARCHAR( 8000) dat a t ypes. I f, however, ( and only if) you find t hat
you need t o creat e a field t o be sized t o accom m odat e st ring or binary
dat a > 8KB, t hen use t he VARCHAR( MAX) or VARBI NARY( MAX) dat a
t ypes respect ively. They are fully int egrat ed wit h nat ive T- SQL
funct ions and do not require special funct ions like t he old TEXT dat a
t ypes did.

1 0 . D a t a Acce ss a nd Tr a n sa ct ion s
Always access t ables in t he sam e order in all your st ored procedures
and t riggers consist ent ly. This helps t o avoid deadlocks. Ot her t hings
t o keep in m ind t o avoid deadlocks are: Keep your t ransact ions as
short as possible. Touch as lit t le dat a as possible during a t ransact ion.

Shane Lively & Michael Sarsany

Page 17 of 24

SQL Server St andards
Version 1.5
Never, ever wait for user input in t he m iddle of a t ransact ion. Do not
use higher level locking hint s or rest rict ive isolat ion levels unless t hey
are absolut ely needed. Make your front - end applicat ions deadlockint elligent , t hat is, t hese applicat ions should be able t o resubm it t he
t ransact ion in case t he previous t ransact ion fails w it h error 1205. I n
your applicat ions, process all t he result s ret urned by SQL Server
im m ediat ely so t hat t he locks on t he pr ocessed rows are released,
hence no blocking.
Always check t he global variable @@ERROR im m ediat ely aft er
execut ing a dat a m anipulat ion st at em ent ( like
I NSERT/ UPDATE/ DELETE) , so t hat you can rollback t he t ransact ion in
case of an error ( @@ERROR will be great er t han 0 in case of an error) .
This is im port ant , because, by default , SQL Server will not rollback all
t he previous changes wit hin a t ransact ion if a part icular st at em ent
fails. Execut ing SET XACT_ABORT ON can change t his behavior. The
@@ROWCOUNT variable also plays an im port ant role in det erm ining
how m any rows were affect ed by a previous dat a m anipulat ion ( also,
ret rieval) st at em ent , and based on t hat you could choose t o com m it or
rollback a part icular t ransact ion.
Sam ple t ransact ion:
declare @sql_error int
set @sql_error = 0
begin transaction
update dbo.tbCacLic
set
sintLicCapacity = source.sintNewLicCapacity,
chrLastUpdtId = 'myLogin',
dtmLastUpdt = getDate()
from
dbo.tbCacLic as target
inner join #dcfsOldLic as source
on target.intAplySiteId = source.intAplySiteId
select @sql_error = @@error
if @sql_error = 0
begin
commit transaction
drop table #dcfsOldLic
end
else
begin
rollback transaction
end

Shane Lively & Michael Sarsany

Page 18 of 24

SQL Server St andards
Version 1.5

1 2 . Er ror H an dlin g
Alt hough som e procedural processes m ay not require addit ional error
handling, as shown above in t he Dat a Access and Transact ions sect ion
t here m ay be inst ances wit hin your st or ed procedures you wish t o
handle errors m ore gracefully. You can use error handling t o rollback
ent ire t ransact ions if one piece fails, report a single failed process
wit hin a procedure back t o t he calling applicat ion…et c. There are som e
exam ples below of proper im plem ent at ion of error handling wit hin a
SQL Server st ored procedure.
SQL Server 7.0 – 9.0( 2005) – Use t his m et hodology t o handle errors
in versions previous t o SQL 2008 ( 10.0) .
- Tally errors. Rollback if failure occurs anywhere in proc.
CREATE PROCEDURE dbo.spDoStuff
@var1 int
AS
SET NOCOUNT ON
--declare/initialize error counter
DECLARE @err int
SELECT @err = 0
BEGIN TRAN
DELETE FROM MyTable
WHERE Col1 = @var1
SET @err = @err + @@ERROR
INSERT INTO MyOtherTable(Col1)
SELECT @var1
SET @err = @err + @@ERROR
IF @err = 0
BEGIN
COMMIT TRAN
RETURN 0
END
ELSE
BEGIN
ROLLBACK TRAN
RETURN @err
END

- End processing when error is reached and ret urn error t o applicat ion.
CREATE PROCEDURE dbo.spDoStuff
@var1 int
AS
SET NOCOUNT ON
--declare error counter

Shane Lively & Michael Sarsany

Page 19 of 24

SQL Server St andards
Version 1.5
DECLARE @err int
BEGIN TRAN
DELETE FROM MyTable
WHERE Col1 = @var1
SET @err = @err + @@ERROR
IF @err > 0 GOTO ERROR_HDLR
INSERT INTO MyOtherTable(Col1)
SELECT @var1
SET @err = @err + @@ERROR
IF @err > 0 GOTO ERROR_HDLR
GOTO END_PROC
-- Handle Errors
ERROR_HDLR:
ROLLBACK TRANSACTION
RETURN @err
-- Return & Exit
END_PROC:
COMMIT TRANSACTION
RETURN 0

SQL Server 10.0( 2008) and great er – SQL version 10.0 has added
Try/ Cat ch funct ionalit y and new funct ions t o report error st at us t o
enhance error handling. You m ay im plem ent t his m et hodology when
developing in SQL 10.0 or higher. Exam ple( s) below.
CREATE PROCEDURE dbo.spDoStuff
@var1 int
AS
SET NOCOUNT ON
BEGIN TRY
BEGIN TRAN
DELETE FROM MyTable
WHERE Col1 = @var1
INSERT INTO MyOtherTable(Col1)
SELECT @var1
COMMIT TRANSACTION
END TRY
GO
BEGIN CATCH
SELECT
ERROR_NUMBER() as ErrorNumber,
ERROR_MESSAGE() as ErrorMessage
-- Test XACT_STATE for 1 or -1.
-- XACT_STATE = 0 means there is no transaction and
-- a commit or rollback operation would generate an error.

Shane Lively & Michael Sarsany

Page 20 of 24

SQL Server St andards
Version 1.5
-- Test whether the transaction is uncommittable.
IF (XACT_STATE()) = -1
BEGIN
PRINT
N'The transaction is in an uncommittable state. ' +
'Rolling back transaction.'
ROLLBACK TRAN
END
-- Test whether the transaction is active and valid.
IF (XACT_STATE()) = 1
BEGIN
PRINT
N'The transaction is committable. ' +
'Committing transaction.'
COMMIT TRAN
END
END CATCH

1 3 . For e ign Ke y a nd Ch e ck Const r a in t s
Unique foreign key const raint s should ALWAYS be enforced across
alt ernat e keys whenever possible. Not enforcing t hese const raint s will
com prom ise dat a int egrit y.
Perform all your referent ial int egrit y checks and dat a validat ions using
const raint s ( foreign key and check const raint s) inst ead of t riggers, as
t hey are fast er. Lim it t he use t riggers only for audit ing, cust om t asks
and validat ions t hat cannot be perform ed using const raint s.
Const raint s save you t im e as well, as you don't have t o writ e code for
t hese validat ions, allowing t he RDBMS t o do all t he work for you.

1 4 . Cu rsor Usa ge
Try t o avoid server side cursors as m uch as possible. Always st ick t o a
'set - based approach' inst ead of a 'procedural approach' for accessing
and m anipulat ing dat a. Cursors can oft en be avoided by using SELECT
st at em ent s inst ead or at worst , t em porary t ables and/ or t able
variables.
Should t he need arise where cursors are t he only opt ion, avoid using
dynam ic and updat e cursors. Make sure you define your cursors as
local, forward only t o increase perform ance and decrease overhead.
Sam ple Cursor:
DECLARE @var1 int
DECLARE MyCursor CURSOR LOCAL FAST_FORWARD FOR

Shane Lively & Michael Sarsany

Page 21 of 24

SQL Server St andards
Version 1.5
SELECT Col2
FROM MyTable1
WHERE Col1 = 5
OPEN MyCursor
FETCH NEXT FROM MyCursor INTO @var1
WHILE (@@fetch_status -1)
BEGIN
IF (@@fetch_status -2)
BEGIN
DELETE FROM MyTable2
WHERE Col1 = @var1
END
FETCH NEXT FROM MyCursor INTO @var1
END
CLOSE MyCursor
DEALLOCATE MyCursor

1 5 . Te m por a r y Ta bles an d Ta ble Va r iables
Use t em porary t ables ( e.g. # NslClaim s) only when absolut ely
necessary. When t em porary st orage is needed wit hin a T- SQL
st at em ent or procedure, it ’s recom m ended t hat you use local t able
variables ( e.g. @NslClaim s) inst ead if t he am ount of dat a st ored is
relat ively sm all. This elim inat es unnecessary locks on syst em t ables
and reduces t he num ber of recom piles on st ored procedures. This also
increases perform ance as t able variables are creat ed in RAM, which is
significant ly fast er t han physical disk. You can increase perform ance
on t em porary t ables and t able variables in som e inst ances by applying
indexes. However, SQL 2005 and great er handles indexes on t em p
t ables and variables m uch bet t er t han SQL 2000. Also keep in m ind
t hat when using indexes it can decrease perform ance on insert s and
updat es so use caut ion when choosing indexed colum ns.

1 6 . Pa r am e t e r Sn iffin g – Be W ar n ed
Wit h SQL Server version 9.0 and great er t he dat abase engine has
enhanced param et er sniffing capabilit y according t o Microsoft . This
funct ionalit y should be m onit ored wit h caut ion as we found t hat it has
bugs. Param et er sniffing cannot be t urned off...and has been deem ed
a “ feat ure” of SQL Server. I t basically sniffs t he values of incom ing
st ored procedure and funct ion param et ers and t ries t o adj ust t he
query opt im izat ion plan accordingly. The problem is under m any
scenarios it adj ust s it for t he worse and severely affect s t he
perform ance of t he procedure.
There is, however, a work around. See t he exam ple below. By using
t his m et hod you w ill in effect bypass param et er sniffing. I would

Shane Lively & Michael Sarsany

Page 22 of 24

SQL Server St andards
Version 1.5
suggest only using t his where you find problem s wit h param et er
sniffing.
CREATE PROCEDURE dbo.spDoStuff
@var1 int,
@var2 varchar(20)
AS
SET NOCOUNT ON
---Bypass parameter sniffing-DECLARE @var1a int,
@var2a varchar(20)
SELECT @var1a = @var1,
@var2a = @var2
------end bypass----------SELECT *
FROM MyTable
WHERE col1 = @var1a
and col2 = @var2a

1 7 . D a t a ba se D e sign – Be st Pra ct ice s
Using SQL Servers RDBMS plat form t o it s fullest pot ent ial is
encouraged. Below are a few t ips t o aide in m axim izing t he built in
feat ures of relat ional dat abase st ruct ures.
•

Ut ilize enforced relat ionships bet ween t ables t o prot ect dat a
int egrit y when possible. Always rem em ber...garbage
in....garbage out . The dat a will only ever be as good as t he
int egrit y used t o st ore it .

•

Take care t o norm alize dat a as m uch as possible while st ill
achieving peak perform ance and m aint ainabilit y. Overnorm alizat ion can also be an issue as it can have a severe effect
on perform ance and dat a m aint enance and cause un- needed
overhead. Ent it ies and t heir proposed uses should be st udied t o
form ulat e a dat a m odel t hat can balance int egrit y, scalabilit y and
perform ance.

•

Make use of aut o- num bered surrogat e keys on all t ables. This
can reduce dat a st orage where com pound prim ary and foreign
keys are prevalent and sim plify relat ionships bet ween dat a when
norm alizing dat a st r uct ures and writ ing queries.

•

Alw a ys use prim ar y keys on t ables! Even if you are enforcing
int egrit y t hrough ot her m eans ( i.e. business layer, unique t able

Shane Lively & Michael Sarsany

Page 23 of 24

SQL Server St andards
Version 1.5
index) always put a prim ary key on a t able. Tables wit h no
prim ary key are a problem wait ing t o happen.
•

Ut ilize indexes and fill fact ors correct ly. Not hing can speed up
dat a t hroughput m ore t han correct ut ilizat ion of clust ered
indexes, regular indexes and fill fact ors. This can be t ricky
business but SQL Server has a sm all host of t ools t hat can
assist . Not hing bet t er t han experience when it com es t o
opt im izing queries and insert / updat e perform ance. I f you ar e
unsure how t o proceed wit h opt im izat ions consult t he DBA.

•

Dat abase securit y is always a concern. I SBE has im plem ent ed
funct ionalit y t o incr ease securit y by obscuring server and
dat abase connect ivit y inform at ion using CI AM and I WAS as well
as disabling SQL Server funct ionalit y t hat can be used
m aliciously or used t o gain cont rol of a dat abase server. Close
at t ent ion m ust be paid when developing front end applicat ions
and st ored procedures t o prot ect against SQL inj ect ion at t acks.
Make sure t o consult t he DBA when est ablishing your dat abase
securit y m odel.

Shane Lively & Michael Sarsany

Page 24 of 24