Joe Celko s SQL for Smarties - Advanced SQL Programming P6. In the SQL database community, Joe Celko is a well-known columnist and purveyor of valuable insights. In Joe Celko's SQL for Smarties: Advanced SQL Programming, he picks up where basic SQL training and experience leaves many database professionals and offers tips, techniques, and explanations that help readers extend their capabilities to top-tier SQL programming. Although Celko denies that the book is about database theory, he nevertheless alludes to theory often to buttress his practical points. This title is not for novices, as the author points out. Instead, its intended audience. | 22 CHAPTER 1 DATABASE DESIGN CREATE TABLE Bar bar_key INTEGER NOT NULL PRIMARY KEY other_key INTEGER NOT NULL UNIQUE . Overlapping Keys But let s get back to the nested keys. Just how far can we go with them My favorite example is a teacher s schedule kept in a table like this I am leaving out reference clauses and check constraints CREATE TABLE Schedule teacher_name VARCHAR 15 NOT NULL class_name CHAR 15 NOT NULL room_nbr INTEGER NOT NULL period INTEGER NOT NULL PRIMARY KEY teacher_name class_name room_nbr period That choice of a primary key is the most obvious one use all the columns. Typical rows would look like this Mr. Celko Database 101 222 6 The rules we want to enforce are 1. A teacher is in only one room each period. 2. A teacher teaches only one class each period. 3. A room has only one class each period. 4. A room has only one teacher in it each period. Stop reading and see what you come up with for an answer. Okay now consider using one constraint for each rule in the list thus. CREATE TABLE Schedule_1 -- version one WRONG teacher_name VARCHAR 15 NOT NULL class_name CHAR 15 NOT NULL room_nbr INTEGER NOT NULL period INTEGER NOT NULL UNIQUE teacher_name room_nbr period -- rule 1 UNIQUE teacher_name class_name period -- rule 2 Schema and Table Creation 23 UNIQUE class_name room_nbr period rule 3 UNIQUE teacher_name room_nbr period rule 4 PRIMARY KEY teacher_name class_name room_nbr period We know that there are four ways to pick three things from a set of four things. While column order is important in creating an index we can ignore it for now and then worry about index tuning later. I could drop the primary key as redundant if I have all four of these constraints in place. But what happens if I drop the primary key and then one of the constraints CREATE TABLE Schedule_2 still wrong teacher_name VARCHAR 15 NOT NULL class_name CHAR 15 NOT NULL room_nbr INTEGER NOT NULL period INTEGER NOT NULL UNIQUE teacher_name room_nbr period -- rule 1 UNIQUE .
