Sams Microsoft SQL Server 2000 Unleashed 2nd Edition Dec 2002 ISBN 0672324679

Listing 12.3 Defining Columns with CREATE TABLE CREATE TABLE yourdb.dbo.employee Emp_no int, Lname varchar20, Fname varchar20, Phone char13, Dept smallint, Salary money Column Pr

This section examines how to use T-SQL to create tables You will see how to define table columns and set properties for the columns Also covered is defining a location for the table,

adding constraints, and making modifications to existing tables

Defining Columns

In defining a column, you assign a name and a datatype to the column Depending on the datatype you choose, you might also have to assign parameters to the datatype, such as a length for

a char() column Listing 12.3 shows a simple CREATE TABLE

statement defining six columns

Listing 12.3 Defining Columns with CREATE TABLE

CREATE TABLE yourdb.dbo.employee

(

Emp_no int,

Lname varchar(20),

Fname varchar(20),

Phone char(13),

Dept smallint,

Salary money

)

Column Properties

Columns also can have properties assigned to them These

properties can address whether a value must be provided for a

provides a value for the column, as is the case with the

identity property

NULL or NOT NULL

When writing your create table scripts, it is always good form to explicitly state whether a column should or should not contain nulls The SQL Server default is not to allow nulls The ANSI-92 standard is to allow nulls To further confuse matters, the

database option 'ANSI_NULL_DEFAULT' can be set so that SQL Server matches the ANSI-92 standard It can also be set at the session level As a matter of fact, if you run your script from Query Analyzer, it overrides the SQL Server default and allows nulls if not specified I hope I've made my point that it is best to explicitly specify the NULL property so you know for sure what it's going to be Listing 12.4 expands on the previous example and properly specifies NULL or NOT NULL

Listing 12.4 Defining Column NULL Properties with

CREATE TABLE

CREATE TABLE yourdb.dbo.employee

(

Emp_no int NOT NULL,

Lname char(20) NOT NULL,

Fname char(20) NOT NULL,

Phone char(13) NULL,

Dept smallint NOT NULL,

Salary int NULL

)

It is beyond the scope of this section to enter the debate on whether columns should ever allow nulls That being said, I'll go

ahead and put in my advice If a column is defined as NULL, no value needs to be entered in that column when inserting or

updating data By defining columns as NOT NULL and providing

a default value where possible, your data will be more

consistent and easier to work with If you allow nulls, you and the development team must always be aware of the effect nulls can have on querying the database

Identity Columns

Another common property specified when creating tables is the

IDENTITY property This property, used in conjunction with the integer datatypes (although decimal can be used with a scale of 0), automatically generates a unique value for a column This is extremely useful for generating what is referred to as a

surrogate primary key Purists will say that the primary key,

or unique row identifier, should be derived from a column or combination of columns that are valid attributes of the entity In the employee table I have been using in the examples, without

an employee key being generated, I would have to combine last name, first name, and phone number as the primary key Even then, if John Smith Jr and John Smith Sr had the same phone number, this combination would fail to guarantee uniqueness This is where IDENTITY comes in By generating a unique value for each row entered, I have satisfied the need for a unique key

on the row

When implementing an IDENTITY property, you supply a seed and an increment The seed is the start value for the numeric

count, and the increment is the amount by which it grows A seed of 10 and an increment of 10 would produce 10, 20, 30,

40, and so on If not specified, the default seed value is 1 and the increment is 1 Listing 12.5 adds to the script by setting an

IDENTITY value that starts at 100 and increments by 10

CREATE TABLE

CREATE TABLE yourdb.dbo.employee

(

Emp_no int IDENTITY (100, 10) NOT NULL,

Lname char(20) NOT NULL,

Fname char(20) NOT NULL,

Phone char(13) NULL,

Dept smallint NOT NULL,

Salary int NULL

)

Defining Table Location

As databases scale in size, the physical location of database objects, particularly tables and indexes, becomes crucial

Consider two tables, Employee and Dept, which are always

queried together If they are located on the same physical disk, contention for hardware resources slows performance SQL

Server enables you to specify where a table (or index) is stored This not only affects performance, but planning for backups as well By dedicating a read-only table to a filegroup, you only need to back up the filegroup once If your table contains text

or image data, you can also specify where it should be stored The location of the table is specified with the ON clause, and

TEXTIMAGE ON indicates where the text and image locaters

should point In Listing 12.6, you create the employee and dept tables, place them on two different filegroups, and store the image for the employee security photo on yet another filegroup Note that the filegroups must exist before the tables are

created For information on filegroups, see Chapter 11,

"Creating and Managing Databases."

Specific Filegroups

CREATE TABLE yourdb.dbo.employee

(

Emp_no int IDENTITY (100, 10) NOT NULL,

Lname char(20) NOT NULL,

Fname char(20) NOT NULL,

Phone char(13) NULL,

Dept smallint NOT NULL,

Photo image NULL,

Salary int NULL

)

ON FGDISK1

TEXTIMAGE_ON FGDISK3

GO

CREATE TABLE yourdb.dbo.dept

(

Dept_no smallint IDENTITY (10, 10) NOT NULL,

Name varchar(20) NOT NULL,

Description varchar(80) NOT NULL,

Loc_code char(2) NULL

)

ON FGDISK2

Defining Table Constraints

Constraints provide us with the means to enforce data integrity

In addition to NULL/NOT NULL, which was covered in a previous section, SQL Server provides five constraint types: PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK, and DEFAULT

Constraints are covered in detail in Chapter 14, so in the

context of creating tables, this chapter will concentrate on the syntax for adding constraints

primary keys to both tables and creating a foreign key on the

employee table that references the dept table

Listing 12.7 Syntax for Creating Constraints with

CREATE TABLE

CREATE TABLE yourdb.dbo.employee

(

Emp_no int IDENTITY (100, 10)CONSTRAINT EMP_PK PRIMARY KEY NOT NULL,

Lname char(20) NOT NULL,

Fname char(20) NOT NULL,

Phone char(13) NULL,

Dept smallint CONSTRAINT EMP_DEPT_FK REFERENCES dept(dept_no)NOT NULL,

Photo image NULL,

Salary int NULL

)

ON FGDISK1

TEXTIMAGE_ON FGDISK3

go

CREATE TABLE yourdb.dbo.dept

(

Dept_no smallint IDENTITY (10, 10) CONSTRAINT DEPT_PK PRIMARY KEY NOT NULL, Name varchar(20) NOT NULL,

Description varchar(80) NOT NULL,

Loc_code char(2) NULL

)

ON FGDISK2

In the following example, CREATE TABLE is run first, and then

ALTER TABLE is run to add the constraints Listing 12.8 shows

how separating constraint creation from table creation makes

the script easier to read and more flexible

Listing 12.8 Syntax for Creating Constraints with

CREATE TABLE dbo.Product (

ProductID int IDENTITY (1, 1) NOT NULL ,

ProductName nvarchar (40) NOT NULL ,

SupplierID int NULL ,

CategoryID int NULL ,

QuantityPerUnit nvarchar (20) NULL ,

UnitPrice money NULL ,

UnitsInStock smallint NULL ,

UnitsOnOrder smallint NULL ,

ReorderLevel smallint NULL ,

Discontinued bit NOT NULL

)

GO

ALTER TABLE dbo.Product ADD

CONSTRAINT DF_Product_UnitPrice DEFAULT (0) FOR UnitPrice, CONSTRAINT PK_Product PRIMARY KEY (ProductID),

CONSTRAINT CK_Product_UnitPrice CHECK (UnitPrice >= 0)

GO

ALTER TABLE dbo.Product ADD

CONSTRAINT FK_Product_Categories FOREIGN KEY

(CategoryID) REFERENCES dbo.Categories (CategoryID)

GO

Adding/Removing/Modifying Table Columns

Using T-SQL

The previous example touched on using ALTER TABLE to add

constraints to an existing table Although this is a common use

of the ALTER TABLE command, you can actually change several

properties of a table The following lists the types of changes

Change the datatype or NULL property of a column

Add new columns or drop existing columns

Add or drop constraints

Enable or disable CHECK and FOREIGN KEY constraints

Enable or disable triggers

Changing the Datatype

The ALTER COLUMN clause of ALTER TABLE can be used to

modify the NULL property or datatype of a column Listing 12.9

shows an example of changing the datatype of a column

Listing 12.9 Changing the Datatype of a Column with ALTER TABLE

ALTER TABLE product

ALTER COLUMN ProductName varchar(50)

You must be aware of several restrictions when you modify the datatype of a column The following rules apply when altering columns:

A text, image, ntext, or timestamp column can't be

modified

The column can't be the ROWGUIDCOL for the table

by a computed column

The column can't be a replicated column

If the column is used in an index, the column length can only be increased in size In addition, it must be a varchar,

nvarchar, or varbinary datatype, and the datatype cannot change

If statistics have been generated using CREATE STATISTICS, the statistics must first be dropped

The column can't have a PRIMARY KEY or FOREIGN KEY

constraint or be used in a CHECK or UNIQUE constraint; the exception is that a column with a CHECK or UNIQUE

constraint, if defined as variable length, can have the length altered

A column with a default defined for it can only have the

length, nullability, or precision and scale altered

If a column has a schema-bound view defined on it, the same rules that apply to columns with indexes apply

Changing some datatypes can result in changing the data For example,

changing from nchar to char could result in any extended characters being

converted Similarly, changing precision and scale could result in data truncation.

Other modifications such as changing from char to int might fail if the data

doesn't match the restrictions of the new datatype When changing datatypes,

always validate that the data conforms to the new datatype.

Adding and Dropping Columns

Columns are added to a table with the ADD COLUMN clause

Listing 12.10 illustrates adding a column to the product table

Listing 12.10 Adding a Column with ALTER TABLE

ALTER TABLE product

ADD ProdDesc varchar(100) NULL

SQL Server adds the column, and in this case allows a NULL

value for all rows If NOT NULL is specified, then the column must be an identity column or have a default specified Note that even if a default is specified, if the column allows nulls, the column will not be populated with the default Use the WITH

VALUES clause to override this and populate the column with the default

With some restrictions, columns can also be dropped from a table The syntax for dropping a column is shown in Listing

12.11 Multiple columns can be specified, separated by a

comma

Listing 12.11 Dropping a Column with ALTER TABLE

DROP COLUMN ProdDesc

The following columns cannot be dropped:

An indexed column

Replicated columns

Columns used in CHECK, FOREIGN KEY, UNIQUE, or PRIMARY KEY constraints

Columns associated with a default or bound to a default object

A column that is bound to a rule

Care should be taken when using ALTER TABLE to modify columns with existing

data When adding, dropping, or modifying columns, SQL Server places a

schema lock on the table, preventing any other access until the operation

completes Changes to columns in tables with many rows can take a long time to

complete and generate a large amount of log activity.

You should be aware that if you want to change a column's

name, it is not necessary to drop it and then add a new column Column names can be changed using sp_rename As with any database object, consider the effects the rename might have on other objects or queries that reference the column The syntax for changing a column name is EXEC sp_rename 'northwind

Databases

By Paul Jensen and Ray Rankins

IN THIS CHAPTER

What Makes Up a SQL Server Database?

Data Storage in SQL Server

Database Files

Creating Databases

Managing Databases

Setting Database Options

The database is, of course, SQL Server's sole reason for

existence This chapter will examine what a database consists

of, how to create one, and the ongoing management

requirements of a database

by Paul Jensen

IN THIS CHAPTER

Types of Data Integrity

Enforcing Data Integrity

Constraints

Rules

Defaults

Ensuring the integrity of data is one of the most important tasks

of an administrator Key business decisions are often made

based on information in the database; if the data is

misrepresented, incorrect conclusions might be drawn Consider

a car manufacturer who uses a product code R01 (R zero one)

to represent every red car sold To predict next year's sales of red cars, they run a query on the database to count the

instances of R01 They determine that they sold far fewer red cars than expected, and reduce production Halfway through the year, they run out of red cars On closer inspection of the data, they determine that they had actually sold plenty of red cars, but the data entry personnel had in many cases

incorrectly entered the code as Ro1 (R oh one), R0l (R zero L)

or Rol (R oh L) So does the blame fall on the data entry

personnel? Not likely Integrity constraints to prevent incorrect entries are the proper solution When it comes to data integrity, the buck stops at the administrator's desk

This chapter focuses on enforcing integrity through the use of constraints, rules, and defaults Data integrity can also be

enforced at the application level, which is a subject for a book

on application design, and through stored procedures and

triggers Because stored procedures and triggers have

additional functionality outside of data integrity, they are

covered in separate chapters of their own Check out Chapter

28, "Creating and Managing Stored Procedures in SQL Server," and Chapter 29, "Creating and Managing Triggers" to learn more

Chapter 28 Creating and Managing Stored Procedures in SQL Server

by Ray Rankins

IN THIS CHAPTER

Advantages of Stored Procedures

Creating and Executing Stored Procedures

Deferred Name Resolution

Viewing and Modifying Stored Procedures

Using Input Parameters

Using Output Parameters

Returning Procedure Status

Cursors in Stored Procedures

Nested Stored Procedures

Using Temporary Tables in Stored Procedures

Using the table Datatype

Remote Stored Procedures

Debugging Stored Procedures with Query Analyzer

Debugging with Microsoft Visual Studio and Visual Basic System Stored Procedures

Stored-Procedure Performance

Using Dynamic SQL in Stored Procedures

Autostart Procedures

Extended Stored Procedures

Stored Procedure Coding Guidelines and Limitations

A stored procedure is one or more SQL commands stored in a

database as an executable object Stored procedures can be called interactively, from within client application code, from within other stored procedures, and from within triggers Par-ameters can be passed to and returned from stored procedures

to increase their usefulness and flexibility A stored procedure can also return a number of resultsets and a status code