Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 522 Part IV Developing with SQL Server The file sizes and growth options can be adjusted in code with the ALTER DATABASE DDL command and the MODIFY FILE option. The following code sets NewDB’s data file to manual growth and sets the size to 25MB: ALTER DATABASE NewDB MODIFY FILE (Name = NewDB, SIZE = 25MB, MAXSIZE = 2Gb, FILEGROWTH = 0); To list the databases using code, query the sys.databases catalog view. Best Practice M any DBAs detest the default autogrowth settings because the database is locked during an autogrowth. Growing by 1MB per growth is probably far too small and will cause frequent interruptions. Another common error is to set the autogrowth to a percentage. As the database grows, so will the growth size. For serious production databases the best solution is to monitor the data size and manually grow the database, but leave autogrowth on as a safety factor. Using multiple files Both the data file and the transaction log can be stored on multiple files for improved performance and to allow for growth. Any additional, or secondary, data files have an .ndf file extension by default. If the database uses multiple data files, then the first, or primary, file will contain the system tables. While it does not enable control over the location of tables or indexes, this technique does reduce the I/O load on each disk subsystem. SQL Server attempts to balance the I/O load by splitting the inserts among the multiple files according to the free space available in each file. As SQL Server balances the load, rows for a single table may be split among multiple locations. If the database is configured for automatic growth, all of the files will fill up before SQL Server increases the size of the files. Creating a database with multiple files To create a database with multiple files using Management Studio, add the filename to the file grid in the Files page of the Database Properties dialog (see Figure 20-3). To create a database with multiple data files from code, add the file locations to the CREATE DATABASE DDL command using the ON option: CREATE DATABASE NewDB ON PRIMARY 522 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 523 Creating the Physical Database Schema 20 FIGURE 20-3 Creating a database with multiple files using SQL Server Management Studio (NAME = NewDB, FILENAME = ‘e:\SQLData\NewDB.mdf’), (NAME = NewDB2, FILENAME = ‘f:\SQLData\NewDB2.ndf’) LOG ON (NAME = NewDBLog, FILENAME = ‘g:\SQLLog\NewDBLog.ldf’), (NAME = NewDBLog2, FILENAME = ‘h:\SQLLog\NewDBLog2.ldf’); Result: The CREATE DATABASE process is allocating 0.63 MB on disk ‘NewDB’. The CREATE DATABASE process is allocating 1.00 MB on disk ‘NewDB2’. 523 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 524 Part IV Developing with SQL Server The CREATE DATABASE process is allocating 1.00 MB on disk ‘NewDBLog’. The CREATE DATABASE process is allocating 1.00 MB on disk ‘NewDBLog2’. To list the files for the current database using code, query the sys.databases catalog view. Modifying the files of an existing database The number of files for an existing database may be easily modified. If the data is filling the drive, another data file can be added to the database by adding it to the database file grid. Add the new filename and location to the database properties file grid in the same way that the files were initially created. In code, a file can be added to an existing database using the ALTER DATABASE DDL command and the ADD FILE option. The file syntax is identical to that used to create a new database. The following code adds a third file to NewDB: ALTER DATABASE NewDB ADD FILE (NAME = NewDB3, FILENAME = ‘i:\SQLData\NewDB3.ndf’, SIZE = 10MB, MAXSIZE = 2Gb, FILEGROWTH = 20); Result: Extending database by 10.00 MB on disk ‘NewDB3’. If a file is no longer desired because the disk subsystem is being retired or designated for another use, one of the data or transaction log files can be deleted by shrinking the file using DBCC ShrinkFile and then deleting it in Management Studio by selecting the file and pressing Delete. Using T-SQL code, remove additional files with the ALTER DATABASE REMOVE FILE DDL command. The following code removes the data file added earlier: DBCC SHRINKFILE (NewDB3, EMPTYFILE) ALTER DATABASE NewDB REMOVE FILE NewDB3; Result: DbId FileId CurrentSize MinimumSize UsedPages EstimatedPages 12 5 1280 1280 0 0 The file NewDB3 has been removed. 524 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 525 Creating the Physical Database Schema 20 Planning multiple filegroups A filegroup is an advanced means of organizing the database objects. By default, the database has a single filegroup — the primary filegroup. By configuring a database with multiple filegroups, new objects (tables, indexes, and so on) can be created on a specified filegroup. This technique can support two main strategies: ■ Using multiple filegroups can increase performance by separating heavily used tables or indexes onto different disk subsystems. ■ Using multiple filegroups can organize the backup and recovery plan by containing static data in one filegroup and more active data in another filegroup. Best Practice C reate a single secondary filegroup, I call mine ‘‘Data,’’ and set it as the default filegroup. This leaves the primary filegroup dedicated for system objects. Creating a database with filegroups To add filegroups to a database using Management Studio, open the Database Properties page from Object Explorer. On the Filegroups page, add the new logical filegroup. Then, on the Files page, you can add the new file and select the filegroup for the new file in the combo box. Using T-SQL, you can specify filegroups for new databases using the Filegroups option. The following code creates the NewDB database with two data filegroups: CREATE DATABASE NewDB ON PRIMARY (NAME = NewDB, FILENAME = ‘d:\SQLData\NewDB.mdf’, SIZE = 50MB, MAXSIZE = 5Gb, FILEGROWTH = 25MB), FILEGROUP Data DEFAULT (NAME = NewDBData, FILENAME = ‘e:\SQLData\NewDBData.ndf’, SIZE = 100MB, MAXSIZE = 50Gb, FILEGROWTH = 100MB) LOG ON (NAME = NewDBLog, FILENAME = ‘f:\SQLLog\NewDBLog.ndf’, SIZE = 100MB, MAXSIZE = 25Gb, FILEGROWTH = 25MB); 525 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 526 Part IV Developing with SQL Server Modifying filegroups Filegroups are easily modified in a manner similar to how files are modified. Using Management Studio, new filegroups may be added, files may be added or removed from a filegroup, and a filegroup may be removed if it is empty. Emptying a filegroup is more difficult than shrinking a file. If there’s data in the filegroup, shrinking a file will only move the data to another file in the filegroup. The tables and indexes must be dropped from the filegroup before the filegroup can be deleted. With Query Editor and T-SQL code, you can add or drop filegroups using the ALTER DATABASE ADD FILEGROUP or ALTER DATABASE REMOVE FILEGROUP commands, respectively, much as you would use the ADD or REMOVE FILE command. Dropping a database A database may be removed from the server by selecting the database in Object Explorer and selecting Delete from the context menu. In code, you can remove a database with the DDL DROP DATABASE command: DROP DATABASE NewDB; There is no undo. Creating Tables Like all relational databases, SQL Server is table-oriented. Once the database is created, the next step is to create the tables. A SQL Server database may include up to 2,147,483,647 objects, including tables, so there’s effectively no limit to the number of tables you can create. Designing tables using Management Studio If you prefer working in a graphical environment, Management Studio provides two primary work sur- faces for creating tables, both of which you can use to create new tables or modify existing ones: ■ The Table Designer tool (see Figure 20-4) lists the table columns vertically and places the column properties below the column grid. ■ The Database Designer tool (see Figure 20-5) is more flexible than the Table Designer form in that it can display foreign-key constraints as connections to other tables. Chapter 6, ‘‘Using Management Studio,’’ explains how to launch and navigate these tools. Each of these tools presents a graphical design of the table. Once the design is complete, Management Studio generates a script that applies the changes to the database. When modifying an existing table, often the script must save the data in a temporary table, drop several items, create the new tables, and reinsert the data. 526 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 527 Creating the Physical Database Schema 20 FIGURE 20-4 Developing the Contact table in the OBXKites sample database using Management Studio’s Table Designer Table Designer displays only the column name and data type (with length), and allows nulls in the column grid. While these are the main properties of a column, I personally find it annoying to have to select each column in order to inspect or change the rest of the properties. Each data type is explained in detail later in this chapter. For some data types, the length property sets the data length, while other data types have fixed lengths. Nulls are discussed in the section ‘‘Creating User-Data Columns,’’ later in this chapter. Once an edit is made to the table design, the Save Change Script toolbar button is enabled. This but- ton displays the actual code that the Table Designer will run if the changes are saved. In addition, the Save Change Script button can save the script to a .sql file so the change can be repeated on another server. For more details about using the Table Designer and Database Designer, see Chapter 6, ‘‘Using Management Studio.’’ 527 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 528 Part IV Developing with SQL Server FIGURE 20-5 Developing the Customer table in the CHA2 sample database using Management Studio’s Database Designer Working with SQL scripts If you are developing a database for mass deployment or repeatable installations, the benefits of develop- ing the database schema in scripts become obvious: ■ All the code is in one location. Working with SQL scripts is similar to developing an applica- tion with VB.NET or C#. ■ The script may be stored in Solutions as a Project using the Solution Explorer. In addition, scripts can be stored in Microsoft SourceSafe or another change-management system. ■ If a database master script contains all the code necessary to generate the database, then the most current version of the database may be installed without running change scripts or restoring a backup. ■ An installation that is a fresh new database, as opposed to a backup or detached database, is beneficial for testing because it won’t have any residual data. 528 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 529 Creating the Physical Database Schema 20 Working with scripts does have its drawbacks, however: ■ The T-SQL commands may be unfamiliar and the size of the script may become overwhelming. ■ If the foreign-key constraints are embedded within the table, the table-creation order is very picky. If the constraints are applied after the tables are created, the table-creation order is no longer a problem; however, the foreign keys are distanced from the tables in the script. ■ Changes to the database schema must be made using ALTER scripts, which are either integrated into the master script or carefully executed in the correct order. ■ Management Studio database diagrams are not part of the script. The T-SQL commands for working with objects, including tables, are CREATE, ALTER,andDROP.The following CREATE TABLE DDL command from the Outer Banks Kite Store sample database creates the ProductCategory table. The table name, including the name of the owner (dbo), is provided, followed by the table’s columns. The final code directs SQL Server to create the table ON the Data filegroup: CREATE TABLE dbo.ProductCategory ( ProductCategoryID UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL DEFAULT (NEWID()) PRIMARY KEY NONCLUSTERED, ProductCategoryName NVARCHAR(50) NOT NULL, ProductCategoryDescription NVARCHAR(100) NULL ) ON [Data]; To list the tables for the current database using code, query the sys.objects catalog view, filtering for type_desc = ‘USER_TABLE’. Best Practice I consider the schema to be code, and as such it should be handled as code and checked into a version control system. I never develop using the graphic user interfaces in Management Studio. I strictly develop using T-SQL scripts. For extensive examples of building databases and tables with scripts, you can reference this book’s sample databases, which are all developed with scripts and are available on www.sqlserverbible.com. Schemas A schema is an object that exists purely to own database objects, most likely to segment a large database into manageable modules, or to implement a segmented security strategy. 529 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 530 Part IV Developing with SQL Server In previous versions of SQL Server, objects were owned by users. Or rather, objects were owned by schema-objects that were the same as the user-owners, but no one spoke in those terms. In SQL Server 2005, the concepts of users and schema were separated. Users could no longer own objects. Typically, and by default, objects are owned by the dbo schema. The schema name is the third part of the four-part name: Server.database.schema.object; When using custom schemas, other than dbo, every query has to specify the schema. That’s not a bad thing, because using a two-part name improves performance, but always typing a long schema is no fun. Best Practice C reating objects in a schema other than dbo can improve security. Getting the correct schema is one more obstacle that helps prevent SQL injection. To list the schema for the current database using code, query the sys.schemas catalog view. Column names SQL Server is very liberal with table and column names, allowing up to 128 Unicode characters and spaces, as well as both uppercase and lowercase letters. Of course, taking advantage of that freedom with wild abandon will be regretted later when typing the lengthy column names and having to place brackets around columns with spaces. It’s more dangerous to discuss naming conventions with programmers than it is to discuss politics in a mixed crowd. Nevertheless, here’s my two cents. There is a debate over whether table names should be singular or plural. The plural camp believes that a table is a set of rows, just like object-oriented classes, and as such should be named with a plural name. The reasoning often used by this camp is, ‘‘A table of customers is a set of customers. Sets include mul- tiple items, so the table should be named the Customers table, unless you only have one customer, in which case you don’t need a database.’’ From my informal polling, however, the singular-name view is held by about three-fourths of SQL Server developers. These developers hold that the customer table is the customer set, rather than the set of customers. A set of rows is not called a rows set,butarow set, and because tables are generally discussed as singular items, saying ‘‘the Customer table’’ sounds cleaner than ‘‘the Customers table.’’ Most (but not all) developers would agree that consistency is more important than the naming conven- tion itself. Personally, I think that developers choose their naming conventionsasawaytodistancethemselves from sloppy designs they’ve had to work with in the past. Having worked on poorly designed flat-file databases with plural names, I slightly prefer singular names. 530 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 531 Creating the Physical Database Schema 20 Best Practice C onsistency is the database developer’s holy grail. The purpose of naming conventions, constraints, referential integrity, relational design, and even column data type is to bring order and consistency to the data we use to model reality. When faced with a database decision, asking ‘‘Which choice is the most consistent?’’ is a good step toward a solution. Another issue involving differences in naming is the use of underscores to indicate words within the name. For example, some IT shops insist that the order-detail table be named ORDER_DETAIL. Personally, I avoid underscores except in many-to-many resolution tables. Studies have shown that the use of mixed case, such as in the name OrderDetail, is easier to read than all lowercase or all uppercase words. However, studies have also shown that using the underscore is the most readable, and some experts hold firmly to that position. Here are the database-naming conventions I use when developing databases: ■ Use singular table names with no numbers, and a module prefix if useful. ■ For many-to-many resolution tables, use table_mm_table. ■ Set all names in mixed case ( MixedCase) with no underscores or spaces. ■ For the primary key, use the table name + ID. For example, the primary key for the Customer table is CustomerID. ■ Give foreign keys the same name as their primary key unless the foreign key enforces a reflexive/recursive relationship, such as MotherID referring back to PersonID in the Family sample database, or the secondary table has multiple foreign keys to the same primary key, such as the many-to-many reflexive relationship in the Material sample database (BillofMaterials.MaterialID to Material.MaterialID and BillofMaterials.SourceMaterialID to Material.MaterialID). ■ Avoid inconsistent abbreviations. ■ Organize a large complex database with schemas. ■ Use consistent table and column names across all databases. For example, always use LastName followed by FirstName. Filegroups Apart from the columns, the only information normally supplied when a table is being created is the name. However, the table can be created on a specific filegroup if the database has multiple filegroups. The OBX Kites database uses two filegroups for data organization purposes. All data that is modified on a regular basis goes into the Primary filegroup. This filegroup is backed up frequently. Data that is rarely modified (such as the order priority lookup codes) goes into the Static filegroup: 531 www.getcoolebook.com . files using SQL Server Management Studio (NAME = NewDB, FILENAME = ‘e:SQLDataNewDB.mdf’), (NAME = NewDB2, FILENAME = ‘f:SQLDataNewDB2.ndf’) LOG ON (NAME = NewDBLog, FILENAME = ‘g:SQLLogNewDBLog.ldf’), (NAME. strategy. 529 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 530 Part IV Developing with SQL Server In previous versions of SQL Server, objects were owned by users. Or rather, objects were owned. NewDBLog, FILENAME = ‘f:SQLLogNewDBLog.ndf’, SIZE = 100MB, MAXSIZE = 25Gb, FILEGROWTH = 25MB); 525 www.getcoolebook.com Nielsen c20.tex V4 - 07/23/2009 8:26pm Page 526 Part IV Developing with SQL Server Modifying