Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 552 Part IV Developing with SQL Server By default a clustered index is created automatically when the primary key constraint is created. To remove an index use the DROP INDEX command with both the table and index name: DROP INDEX OrderDetail.IxOrderID; Indexes, once created, do not automatically maintain their efficiency. Updates can frag- ment the index and affect the index page’s fill factor. While this chapter mentions index maintenance, Chapter 42, ‘‘Maintaining the Database,’’ details the administrative requirements for index performance. Composite indexes A composite index is a clustered or non-clustered index that includes multiple key columns. Most non- clustered indexes are composite indexes. If you use SQL Server Management Studio’s Index Properties form, composite indexes are created by adding multiple columns to the index in the General page. When creating a composite index with code, it must be declared in a CREATE INDEX DDL statement after the table is created. The following code sample creates a composite clustered index on the Guide table in the CHA2 database: CREATE CLUSTERED INDEX IxGuideName ON dbo.Guide (LastName, FirstName); The order of the columns in a composite index is important. In order for a search to take advantage of a composite index it must include the index columns from left to right. If the composite index is lastname, firstname, a search for firstname will not use the index, but a search for lastname, or lastname and firstname, will. SQL Server can index words within columns using Integrated Full-Text Search, covered in Chapter 19, ‘‘Using Integrated Full-Text Search.’’ Primary keys A primary key can be initially defined as a clustered or non-clustered index. However, in order for the index type to be changed, the primary key constraint must be dropped and recreated — a painful task if numerous foreign keys are present or the table is replicated. For more information on designing primary keys, please see the section ‘‘Primary keys,’’ earlier in this chapter and Chapter 3, ‘‘Relational Database Design.’’ Filegroup location If the database uses multiple named filegroups, the index may be created on a certain filegroup with the ON filegroupname option: CREATE NONCLUSTERED INDEX IndexName ON Table (Columns) ON filegroupname; This option is useful for spreading the disk I/O throughput for very heavily used databases. For example, if a web page is hit by a zillion users per minute, and the main page uses a query that involves 552 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 553 Creating the Physical Database Schema 20 two tables and three indexes, and several disk subsystems are available, then placing each table and index on its own disk subsystem will improve performance. Remember that a clustered index must be in the same location as the table because the clustered index pages and the data pages are merged. The physical location of tables and indexes may be further configured using filegroups and partitioning. For more details on table and index partitioning, refer to Chapter 68, ‘‘Parti- tioning.’’ Index options SQL Server 2008 indexes may have several options, including uniqueness, space allocation, and perfor- mance options. Unique indexes A UNIQUE INDEX option is more than just an index with a unique constraint; index optimizations are available to unique indexes. A primary key or a unique constraint automatically creates a unique index. In Management Studio, a unique index is created by checking the Unique option in the General page of the Index Properties form. In code, an index is set as unique by adding the UNIQUE keyword to the index definition, as follows: CREATE UNIQUE INDEX OrderNumber ON [Order] (OrderNumber); Include columns SQL Server 2005 added the capability to include non-key columns in the leaf level of non-clustered indexes. These non-sorted columns are great for defining covering indexes. Multiple columns may be included, and included columns can be added in the Index Properties dialog or with code: CREATE INDEX ixGuideCovering ON dbo.Guide (LastName, FirstName) INCLUDE (Title) Filtered indexes New for SQL Server 2008, filtered indexes enable DBAs to create indexes that include less than the entire table’s worth of data. Essentially, a WHERE clause is added to the index definition. These are perfect for highly tuned covering indexes. Filtered indexes can be configured in the Filter page of the Management Studio’s Index Properties dialog, or using T-SQL. The following DDL statement creates a filtered non-clustered index that includes only the work orders that are active. Older work orders are ignored by the index: CREATE INDEX IxActiveProduction ON Production.WorkOrders (WorkOrderID, ProductID) WHERE Status = ‘Active’ 553 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 554 Part IV Developing with SQL Server Index fill factor and pad index An index needs a little free space in the tree so that new entries don’t require restructuring of the index. When SQL Server needs to insert a new entry into a full page, it splits the page into two pages and writes two half-full pages back to the disk. This causes three performance problems: the page split itself, the new pages are no longer sequential, and less information is on each page so more pages must be read to read the same amount of data. Because the index is a balanced tree (b-tree), each page must hold at least two rows. The fill factor and the pad index affect both the intermediate pages and the leaf node, as described in Table 20-6. TABLE 20-6 Fill Factor and Pad Index Fill Factor Intermediate Page(s) Leaf Node 0 One free entry 100% full 1–99 One free entry or ≤ fill factor if pad index ≤ Fill factor 100 One free entry 100% full The fill factor only applies to the detail, or leaf, node of the index, unless the PAD INDEX option is applied to the fill factor. The PAD INDEX option directs SQL Server to apply the looseness of the fill factor to the intermediate levels of the b-tree as well. Best Practice T he best fill factor depends on the purpose of the database and the type of clustered index. If the database is primarily for data retrieval, or the primary key is sequential, a high fill factor will pack as much as possible in an index page. If the clustered index is nonsequential (such as a natural primary key), then the table is susceptible to page splits, so use a lower page fill factor and defragment the pages often. The index’s fill factor will slowly become useless as the pages fill and split. The main- tenance plan must include periodic re-indexing to reset the fill factor. Chapter 42, ‘‘Maintaining the Database,’’ includes information on how to maintain indexes. Using Management Studio, the fill factor is set in the Index Properties Options page. In T-SQL code, include the fill factor and index pad options after the CREATE INDEX command. The following code example creates the OrderNumber index with 15 percent free space in both the leaf nodes and the intermediate pages: CREATE NONCLUSTERED INDEX IxOrderNumber ON dbo.[Order] (OrderNumber) WITH FILLFACTOR = 85, PAD_INDEX = ON; 554 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 555 Creating the Physical Database Schema 20 Limiting index locks and parallelism The locking behavior of queries using the index may be controlled using the ALLOW_ROW_LOCKS and ALLOW_PAGE_LOCKS options. Normally these locks are allowed. Index sort order SQL Server can create the index as a descending index. Any query using an ORDER BY clause will still be sorted ascending unless the query’s ORDER BY specifically states DESC. The ASC or DESC option follows the column name in the CREATE INDEX DDL command. The Ignore Dup Key index option The IGNORE_DUPLICATE_KEY option doesn’t affect the index, but rather how the index affects data modification operations later. Normally, transactions are atomic, meaning that the entire transaction either succeeds or fails as a logi- cal unit. However, the IGNORE_DUPLICATE_KEY option directs INSERT transactions to succeed for all rows accepted by the unique index, and to ignore any rows that violate the unique index. This option does not break the unique index. Duplicates are still kept out of the table, so the consis- tency of the database is intact, but the atomicity of the transaction is violated. Although this option might make importing a zillion questionable rows easier, I personally don’t like any option that weakens the ACID (atomic, consistent, isolated, durable) properties of the database. The following command is the same as the previous CREATE UNIQUE INDEX command, but with the IGNORE_DUPLICATE_KEY option: CREATE UNIQUE INDEX OrderNumber ON [Order] (OrderNumber) WITH IGNORE_DUP_KEY = ON The Drop Existing index option The DROP EXISTING option directs SQL Server to drop the current index and rebuild the new index from scratch. This may cause a slight performance improvement over rebuilding every index if the index being rebuilt is a clustered index and the table also has nonclustered indexes, because rebuilding a clus- tered index forces a rebuild of any non-clustered indexes. The Statistics Norecompute index option The SQL Server Query Optimizer depends on data-distribution statistics to determine which index is most significant for the search criteria for a given table. Normally, SQL Server updates these statistics automatically. However, some tables may receive large amounts of data just prior to being queried, and the statistics may be out of date. For situations that require manually initiating the statistics update, the STATISTICS NORECOMPUTE = ON index option disables automatic statistics, but for nearly all indexes this option should be ignored. 555 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 556 Part IV Developing with SQL Server Sort in tempdb The SORT_IN_TEMPDB = ON option modifies the index-creation method by forcing it to use tempdb as opposed to memory. If the index is routinely dropped and recreated, this option may shorten the index- creation time. For most indexes, this option is neither required nor important. Disabling an index An index may be temporarily disabled, or taken offline, using the Use Index check box in the Index Properties ➪ Options page. Using T-SQL, to disable an index use the ALTER INDEX DDL command with the DISABLE option: ALTER INDEX [IxContact] ON [dbo].[Contact] DISABLE During some intensive data import operations, it’s faster to drop the index and recreate it than to update the index with every newly inserted row. The benefit of disabling an index is that the metadata for the index is maintained within the database, rather than depending on the code to recreate the correct index. Disabling a clustered index effectively disables the table. To re-enable an index, use the ALTER INDEX REBUILD WITH command: ALTER INDEX [PKContact0BC6C43E] ON [dbo].[Contact] REBUILD WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF, ONLINE = OFF ) Summary The logical database schema often requires tweaking in order to serve as a physical schema. It’s in the nitty-gritty details of the physical-database schema that the logical design takes shape and becomes a working database within the restrictions of the data types, keys, and constraints of the database prod- uct. Knowing the table-definition capabilities of SQL Server means that you can implement some project features at the server-constraint level, rather than in T-SQL code in a trigger or stored procedure. A few key points about creating the physical schema: ■ DDL code is like any other source code. Write it in script form and keep it under source code control. ■ Be careful with autogrowth. 556 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 557 Creating the Physical Database Schema 20 ■ Set up a separate filegroup for user tables and set it as the default filegroup, and keep user tables off the primary filegroup. ■ Natural keys are good for lookup tables. Use surrogate keys for the other tables. ■ Constraints are faster and more reliable than application code. Always enforce the database rules with constraints. ■ Indexes are easy to create but complex to design, as covered in Chapter 64, ‘‘Indexing Strategies.’’ Within this part of the book, ‘‘Developing with SQL Server,’’ this chapter has provided the code to build the physical schema. From here, the rest of this part continues the development discussion, with several more chapters of T-SQL and a chapter of .NET, and key development ideas. 557 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 558 www.getcoolebook.com Nielsen c21.tex V4 - 07/23/2009 4:48pm Page 559 Programming with T-SQL IN THIS CHAPTER The basics of T-SQL and batches Working with local variables Controlling the flow of the batch Exploring SQL Server objects with code Working with temporary tables and table variables Using multiple a ssignment variable select statements S tandard SQL Data Manipulation Language (DML) commands — SELECT, INSERT, UPDATE,andDELETE — only modify or return data. SQL DML lacks both the programming structure to develop procedures and algorithms, and the database-specific commands to control and tune the server. To compensate, each full-featured database product must complement the SQL standard with some proprietary SQL language extension. Transact-SQL, better known as T-SQL, is Microsoft’s implementation of SQL plus its collection of extensions to SQL. The purpose of T-SQL is to provide a set of procedural and administrative tools for the development of a transactional database. T-SQL is often thought of as synonymous with stored procedures. In reality it’s much more than that, which is why this chapter is about T-SQL and the next chapter covers stored procedures. It may be employed in several different ways within a SQL Server client/server application: ■ T-SQL is used within expressions as part of DML commands ( INSERT, UPDATE,andDELETE) submitted by the client process. ■ It is used within blocks of code submitted to SQL Server from a client as a batch or script. ■ T-SQL functions are used as expressions within check constraints. ■ T-SQL code is used within batches of code that have been packaged within SQL Server as stored procedures, functions, or triggers. Truth be told, this book has been covering T-SQL programming since Chapter 8, ‘‘Introducing Basic Query Flow.’’ The DML commands are the heart of T-SQL. This chapter merely adds the programmatic elements required to develop server-side procedural code. The language features explained in this chapter are the foundation for developing stored procedures, user-defined functions, and triggers. 559 www.getcoolebook.com Nielsen c21.tex V4 - 07/23/2009 4:48pm Page 560 Part IV Developing with SQL Server What’s New with T-SQL Programming? M icrosoft has steadily enhanced Transact-SQL. SQL Server 7 saw unique identifiers, SQL Server 2000 added user-defined functions, and SQL Server 2005 added common table expressions. SQL Server 2008 adds a few juicy new features as well: Topping the list are table-valued parameters and the new user-defined table type, which radically improves how client applications can send complex transactions to SQL Server. In addition, variables may be initialized when they’re declared, and there’s a new shortcut for incrementing variables and columns. Transact-SQL Fundamentals T-SQL is designed to add structure to the handling of sets of data. Because of this, it does not provide several language features that application development needs. If you do a lot of application program- ming development, you’ll find that T-SQL is in many ways the exact opposite of how you think when programming in VB, C#, Java, or any other structured development language. Best Practice S QL Server 2005 added the capability to create stored procedures, functions, and triggers using .NET and the common language runtime. Nevertheless, T-SQL is the native language of SQL Server, a nd it remains the best choice for any data-oriented task. T-SQL batches A query is a single SQL DML statement, and a batch is a collection of one or more T-SQL statements. The entire collection is sent to SQL Server from the front-end application as a single unit of code. SQL Server parses the entire batch as a unit. Any syntax error will cause the entire batch to fail, mean- ing that none of the batch will be executed. However, the parsing does not check any object names or schemas because a schema may change by the time the statement is executed. Terminating a batch A SQL script file or a Query Analyzer window may contain multiple batches. If this is the case, a batch- separator keyword terminates each batch. By default, the batch-separator keyword is GO (similar to how the Start button is used to shut down Windows). The batch-separator keyword must be the only key- word in the line. You can add a comment after the GO. The batch separator is actually a function of SQL Server Management Studio and SQLCMD, not SQL Server. It can be modified in the Query Execution page by selecting Tools ➪ Options, but I don’t rec- ommend creating a custom batch separator (at least not for your friends). 560 www.getcoolebook.com Nielsen c21.tex V4 - 07/23/2009 4:48pm Page 561 Programming with T-SQL 21 Because the GO batch terminator tells Management Studio’s Query Editor to send the batch to the con- nected SQL Server, it can be used to submit the batch multiple times. The following script demonstrates this poor man’s cursor: PRINT ‘I’m a batch.’; go 5 will execute 5 times Result: Beginning execution loop I’m a batch. I’m a batch. I’m a batch. I’m a batch. I’m a batch. Batch execution completed 5 times. Terminating a batch kills all local variables, temporary tables, and cursors created by that batch. DDL commands Some T-SQL DDL commands, such as CREATE PROCEDURE, are required to be the only command in the batch. Very long scripts that create several objects often include numerous GO batch terminators. Because SQL Server evaluates syntax by the batch, using GO throughout a long script also helps locate syntax errors. Switching databases Interactively, the current database is indicated in the Query Editor toolbar and can be changed there. In code, the current database is selected with the USE command. You can insert USE within a batch to specify the database from that point on: USE CHA2; It’s a good practice to explicitly specify the correct database with the USE command, rather than assume that the user will select the correct database prior to running the script. At the end of scripts, I tend to add a USE tempdb database, so Query Editor windows aren’t kept parked in the development database. Executing batches A batch can be executed in several ways: ■ A complete SQL script (including all the batches in the script) may be executed by opening the .sql file with SQL Server Management Studio’s SQL Editor and pressing F5, clicking the ‘‘! Execute’’ toolbar button, pressing Ctrl+E, or selecting Query ➪ Execute. ■ Selected T-SQL statements may be executed within SQL Server Management Studio’s SQL Editor by highlighting those statements and pressing F5, clicking the ‘‘! Execute’’ toolbar button, pressing Ctrl+E, or selecting Query ➪ Execute. 561 www.getcoolebook.com . 07/23/2009 4:48pm Page 560 Part IV Developing with SQL Server What’s New with T -SQL Programming? M icrosoft has steadily enhanced Transact -SQL. SQL Server 7 saw unique identifiers, SQL Server 2000 added. tune the server. To compensate, each full-featured database product must complement the SQL standard with some proprietary SQL language extension. Transact -SQL, better known as T -SQL, is Microsoft s. about T -SQL and the next chapter covers stored procedures. It may be employed in several different ways within a SQL Server client /server application: ■ T -SQL is used within expressions as part