Database Objects

Quote all database objects/fields using square brackets

Reference all objects by owner/schema

Eg:

[dbo].[authors]

Keywords

Use UPPERCASE for all keywords

Eg.

SELECT

    *

FROM

    [dbo].[authors]

Datatypes

Use lowercase for all datatypes

Eg.

DECLARE

    @authorID int

   ,@authorName nvarchar(max)

Table Alias

• All tables should be aliased
• Aliases should be lowercase
• Ideally use the first letter of each word.
• However choose a base alias for each table within the database.

This should therefore be consistent across all queries within the db.

• Where this causes a clash, suffix with a term to distinguish the alias within the query.

Eg.

FROM

    [dbo].[Customer] c

FROM

    [dbo].[CustomerAddress] ca

FROM

    [dbo].[Tree] t_parent

    INNER JOIN [dbo].[Tree] t_child ON ...

Column lists

• Each column must start on a new line
• Indent column list from preceding keyword
• This is required if the table contains an IDENTITY column

SELECT, UPDATE, DELETE, INSERT general rules

Within SELECT, UPDATE, DELETE and INSERT statements

• Align FROM, WHERE, GROUP BY, HAVING and SET clauses. These should begin on a new line, with the same indent as the original select statement.

UPDATE

Always use an table alias in the UPDATE statement and reference the table in a FROM clause

Eg.

UPDATE a

SET

    [AuthorName] = @authorName

   ,[AuthorAge] = @authorAge

FROM

    [dbo].[Author] a

INSERT

• Always include a column list
• Obey rules regarding brackets and column lists

Eg.

INSERT INTO [dbo].[Author]

(

    [AuthorName]

   ,[AuthorAge]

)

FROM

• Indent table list in FROM statement
• All JOINS should begin on a new line
• If the line is too long, ON should begin on a new line, indented from the original table name

Eg.

FROM

    [dbo].[Customer] c

WHERE, HAVING

• Indent all clauses within a WHERE clause
• Each clause should be on a new line
• If there are multiple clauses, pad with an additional indent so that the first character of each statement lines up.

Eg.

WHERE

        table.[AuthorName] = 'Steve'

    AND table.[AuthorAge] > 30

    OR  table.[AuthorName] = 'Dave'

ORDER BY, GROUP BY

• Indent column list
• Each column must start on a new line

Eg.

ORDER BY

    table.[AuthorLastName]

   ,table.[AuthorFirstName]

CASE

• Indent all WHEN and ELSE keywords within a CASE statement
• END keyword should have the same indentation as the original CASE keyword

Eg.

CASE

    WHEN t1.[Col1] = 1 THEN 'First'

    WHEN t1.[Col1] = 2 THEN 'Second'

    ELSE 'Last'

END AS [ColumnPosition]

IF, WHILE

• Always use BEGIN and END  statements with the IF  or WHILE keywords – see rules for BEGIN and END
• WHILE, IF and ELSE should always be at the start of a new line
• Each clause should be on a new line, with the exception of the first
• If there are multiple clauses, pad with an additional indent so that the first character of each statement lines up.

Eg.

IF EXISTS(SELECT * FROM #table)

AND @debug = true

BEGIN

   --do something

END

ELSE

BEGIN

   --do something else

END

WHILE (@rowcount > 0)

BEGIN

   --do something

END --end of @rowcount > 0

Examples

This example shows some more complex WHERE clause statements. 

--Select tree structure

SELECT

    [Col1]

   ,[Col2]

   ,[Col3]

   ,CASE

        WHEN t1.[Col1] = 1 THEN 'First'

        WHEN t1.[Col1] = 2 THEN 'Second'

        ELSE 'Last'

    END AS [ColumnPosition]

FROM

    [dbo].[Tree] t_parent

    INNER JOIN [dbo].[Tree] t_child

        ON t_parent.[Row1] = t_child.[Row1]

        AND t_parent.[TreeID] = t_child.[TreeID]

WHERE

    (

        t2.[Col4] = 3

        OR

        (

                t2.[Col3] < 6

            AND t2.[Col4] > 5

        )

    )

    AND NOT EXISTS

    (

        SELECT

            *

        FROM

            [dbo].[Table5] t5

        WHERE

            t5.[Col2] = t1.[Col2]

    )

GROUP BY...

HAVING ...

--Insert into table1

INSERT [dbo].[Table1]

(

    [Column1]

   ,[Column2]

   ,[Column3]

)

SELECT

    t2.[Column1]

   ,t2.[Column2]

   ,t2.[Column3]

FROM

   [dbo].[Table] t

WHERE ....

--Insert values into table1

INSERT [dbo].[Table1]

(

    [Column1]

   ,[Column2]

   ,[Column3]

)

VALUES

(

    value1

   ,value2

   ,value3

)

--Update Author Name and Age

UPDATE a

SET

    [AuthorName] = @authorName

   ,[AuthorAge] = @authorAge

FROM

    [dbo].[Author] a

    INNER JOIN @AuthorTable at ON a.[AuthorID] = at.[AuthorID]

Use 4 spaces for indenting

Use 4 spaces for indenting in your database source files and remain consistent throughout the file on the number of space chosen for an indent.

Editors will allow you to configure the tab key for 4 spaces (as opposed to the default of 8).

Do not use the tab character.

There should be no tab characters in a text source file.

Most editors, aside from Notepad but including Query Analyzer, will allow you to configure your tab key to insert spaces instead of the tab character.  This approach will promote consistency with source files across projects, and will ensure documents look good when printed or when they are brought into Query Analyzer.

Line Width

Keep code within 87 characters

The width of code should be kept within 87 characters or as close as possible.  If the code is too wide, it has to be scrolled and when printed it will wrap and be not as readable.

Commas

Many of us prefer commas on the left for lists because it is easy to add on new columns without having to add a comma to the last column.  Also, it is easy to see if a comma is missing.

Indent a line with a comma by one less character than the normal indent. This keeps the first and subsequent lines in line.

Eg.

DECLARE

    @authorID int

   ,@authorName nvarchar(max)

Brackets

• A bracket should always appear on its own on a new line
• Brackets should not be indented from a preceeding line
• All items within a bracket should be indented – including a bracket

Eg.

WHERE

    (

        t2.[Col4] = 3

        OR

        (

                t2.[Col3] < 6

            AND t2.[Col4] > 5

        )

    )

    AND NOT EXISTS

    (

        SELECT

            *

        FROM

            [dbo].[Table5] t5

        WHERE

            t5.[Col2] = t1.[Col2]

    )

BEGIN, END

• A BEGIN and END should always appear on its own on a new line
• BEGIN and END should not be indented from a preceeding line
• All items within a BEGIN and END should be indented – including a nested BEGIN and END

·         When there are a lot of lines between the BEGIN and END it is helpful to comment the END so it can be matched up with the BEGIN more easily.

Eg.

IF EXISTS(SELECT * FROM #table)

BEGIN

   --do something

END

ELSE

BEGIN

   --do something else

END

Summary:

Schemas

• Use lowercase for schema names.
• Always alias database objects using the schema name, even if this is the default [dbo] schema
• This applies to both CREATE statements and when referencing objects in FROM, INSERT or UPDATE statements etc.

Table Names

• Pascal Case
• Alpha-numeric
• Avoid underscore
• No Prefix
• Use the Singular Form eg: User, not Users

Linking Table Names

• Linking Tables should be the name of the two tables it is joining, suffixed with Link. Eg a joining table on User and Group would be UserGroupLink

Column Names

• Pascal Case
• Alpha-numeric
• Avoid underscore

• No Prefix
• Format: <TableName(for PK only)><Qualifier><Name>

use the following components in the order below;

• Table Name: Primary keys only; Tables names are used to prefix all columns in dotted format, so this is not necessarily. The exception is the primary key since this is used in foreign keys.
• Qualifier: Optional; Description, to clarify the meaning of the field. For example, if a product has two images, this would clarify the field, eg. FrontImage and RearImage
• Name: Required; This is a database independent “datatype” descriptor which is used to classify the type of data. Below is a common list of standard classifiers. The exception to this is a Boolean. This should be Prefixed with “Is” as this more positively represents the meaning o the value. Flag suffix is considered optional “Flag” or Eg. IsEnabled or IsEnabledFlag

Definitions:

PascalCasing – The first character of each word is capitalized.  Example: FirstName

camelCasing - The first character of each word is capitalized except the first one   Example: firstName

UPPERCASE – All characters are uppercase.  Use these identifiers only for abbreviations (eg: ADO) and for Transact SQL keywords (eg: SELECT Id FROM Table)

Valid Characters

Alphanumeric characters only – In every case only alphanumeric characters (and some situations underscore) are allowed

General Rules

The following rules should apply to all database objects.

·         Clear and unambiguous naming.

The name should provide as much information as possible about an object and provide an obvious connection to references in project documentation.  Choice of names should typically consider a name space much larger than a project—preferably the enterprise.  A name uniquely identifies a database object; its definition should be consistent wherever the object is used.  What might seem clear in a narrow context may lose meaning outside of that context.  Saving keystrokes should never be used as a criterion in selecting a name.

·         Abbreviations should be avoided.

Only when length restrictions apply should they be permitted. When used, abbreviations should follow the abbreviation rules specified below in the Abbreviation Standards section.

·         Alphanumeric characters only – Do not use special characters; restrict names to alphanumeric characters

·         PascalCase: Form names by using an initial capital as the delimiter between words, without embedded spaces or underscores  (e.g.,  InvoiceDate).

I have been working as a software developer, for MSN in London since 2000. My job has quite a large remit. In my time, I have worked on two different web-based content-publishing systems and various other smaller other projects. This means my technology skill set is fairly wide and I get to constantly learn new skills.

So why did I decide to create a blog. Well I figured it would be a good place to store random bits of code I find or write, as I am often found hunting for code I have written in the past. In particular as the strongest SQL "expert" in the team, I am often asked how to do things, so I expect this blog to have a strong focus on SQL.

If you want to find out a bit more about me, I could redirect you to my site - http://www.stevenbates.com, but at the moment, the best I have managed to do is upload a CV. Maybe by posting this, it will actually spur me into doing something with it. :) (Actually I probably would have done, had Tiscalli not introduced the requirement to dial in via their dialup using a modem - a what??)

Why Wizardry? So in my last project, the group manager said he had played with Visual Studio 2003 and a database project and realised most of the database for the new project could be written using SQL Wizards. Ok, I know he wasn't being that naive, but it goes some way to so show how easy some people regard database development. Anyway it led me to use the messenger tag "SQL Wizard" for the rest of the rest of the project