One last quick introduction before we exit this chapter — we want to see the basics of having the Management Studio write our scripts for us. For now, we are going to do this as something of a quick and dirty introduction. Later on, after we’ve learned about the many objects that the scripting tool refer-ences, we will take a more advanced look.
To generate scripts, we go into the Management Studio and right-click on the database for which we want to generate scripts. (In this case, we’re going to generate scripts on our Accountingdatabase.) On the pop-up menu, choose Script Database As➪CREATE To➪New Query Editor Window, shown in Figure 5-10.
Figure 5-10
Whoa! SQL Server generates a heck of a lot more code than we saw when we created our database to begin with. Don’t panic, however — all it is doing is being very explicit in scripting major database set-tings rather than relying on defaults as we did when we scripted it ourselves.
Note that we are not limited to scripting the database — if you want to script other objects in the data-base, just navigate and right click on them much the way that you right-clicked on the Accounting database and, boom!, you’ve got yourself a SQL Script.
As you can see, scripting couldn’t be much easier. Once you get a complex database put together, it still isn’t quite as easy as it seems in this particular demonstration, but it is a lot easier than writing it all out by hand. The reality is that it really is pretty simple once you learn what the scripting options are, and we’ll learn much more about those later in the book.
Summar y
In this chapter, we’ve covered the basics of the CREATE, ALTER, and DROPstatements as they relate to cre-ating a database and tables. There are, of course, many other renditions of these that we will cover as we continue through the book. We have also taken a look at the wide variety of options that we can use in databases and tables to have full control over our data. Finally, we have begun to see the many things that we can use the Management Studio for in order to simplify our lives, and make design and scripting simpler.
At this point, you’re ready to start getting into some hardcore details about how to lay out your tables, and a discussion on the concepts of normalization and more general database design. I am, however, actually going to make you wait another chapter before we get there, so that we can talk about con-straints and keys somewhat before hitting the design issues.
Exercises
1.
Using the Management Studio’s script generator, generate SQL for both the Customers and the Employees tables.2.
Without using the Management Studio, script a database called “MyDB” with a starting database size of 17MB and a starting log size of 5MB — set both the log and the database to grow in 5MB increments.3.
Create a Table called Foo with a single variable length character field called “Col1” — limit the size of Col1 to 50 characters.149
Creating and Altering Tables
6
Constraints
You’ve heard me talk about them, but now it’s time to look at them seriously — it’s time to deal with constraints. SQL Server has had many changes in this area over the last few versions, and that trend has continued with SQL Server 2005.
We’ve talked a couple of times already about what constraints are, but let’s review in case you decided to skip straight to this chapter.
This gets back to the notion that I talked about back in Chapters 1 and 2, where ensuring data integrity is not the responsibility of the programs that use your database, but rather the responsi-bility of the database itself. If you think about it, this is really cool. Data is inserted, updated, and deleted from the database by many sources. Even in stand-alone applications (situations where only one program accesses the database) the same table may be accessed from many different places in the program. It doesn’t stop there though. Your database administrator (that might mean you if you’re a dual role kind of person) may be altering data occasionally to deal with problems that arise. In more complex scenarios, you can actually run into situations where literally hundreds of different access paths exist for altering just one piece of data, let alone your entire database.
Moving the responsibility for data integrity into the database itself has been revolutionary to database management. There are still many different things that can go wrong when you are attempting to insert data into your database, but your database is now proactive rather than reactive to problems. Many problems with what programs allow into the database are now caught much earlier in the development process because, although the client program allowed the data through, the database knows to reject it. How does it do it? Primarily with constraints (datatypes and trig-gers are among the other worker bees of data integrity). Well let’s take a look.
A constraint is a restriction. Placed at either column or table level, a constraint ensures that your data meets certain data integrity rules.
In this chapter, we’ll be looking at the three different types of constraints at a high level:
❑ Entity constraints
❑ Domain constraints
❑ Referential integrity constraints
At a more specific level, we’ll be looking at the specific methods of implementing each of these types of constraints, including:
❑ PRIMARY KEYconstraints
❑ FOREIGN KEYconstraints
❑ UNIQUEconstraints (also known as alternate keys)
❑ CHECKconstraints
❑ DEFAULTconstraints
❑ Rules
❑ Defaults (similar to, yet different from, DEFAULTconstraints)
We’ll also take a very cursory look at triggers and stored procedures (there will be much more on these later) as a method of implementing data integrity rules.