Bob,
I believe there is a bit of a misunderstanding related to your disagreements:
#1"It is not helpful to suggest to neophyte database developers that
character PKs are desirable"
I agree entirely. In fact, I counsel against that on page 29 where I say, "I recommend the use
of 64-bit, sequentially generated integers for primary key columns." I admit, I should have called this out in a sidebar as a best practice. Nevertheless, it is right at the front of the section on how to design primary keys.
The best practice you seem to be arguing against, however, is the following:
"Use fixed character data types like CHAR for primary keys in lookup
tables."
The important clause here is, "in lookup tables". This best practice is
about how one deals with designing primary keys for lookup tables like
Country, State, Locale, etc. For such tables you want a fixed character
data type as the primary key. Fixed, because indexing and searching against variable
length types is much less efficient and character because applications
almost always primarily search lookup tables based on human readable
codes. The alternative would be to create a State table like this:
CREATE TABLE State (
state_id BIGINT NOT NULL PRIMARY KEY,
code CHAR(2) NOT NULL,
name VARCHAR(50) NOT NULL,
UNIQUE INDEX ( code ) );
This approach would have zero performance or design benefit, add additional
application complexity, reduce end user usability, and require an
extra, useless index.
In short, I strongly stand by this best practice as it is in the book.
#2 "including the name of a table in the primary key is done to make
things easier when using CASE tools"
Personally, I do not like the fact that CASE tools are easier to work
with when you follow this best practice. I hate redundant naming, which
is what this best practice causes. However, the fact remains that it is
easier to work with, and more important, collaborate in CASE tools when
you follow this best practice. Even if you do not use a CASE tool, this
best practice does no harm to maintainability, efficiency, or
functionality of the model--the primary things you attempt to impact
with a best practice. I thus stand by this practice even though I find the need for it annoying.
#3 "I also feel that of all the CDs that could have been used in table
2-1, the author could have chosen more neutral examples to be used to
illustrate business data and sample queries."
I have two points to make regarding this issue.
First, what I like about O'Reilly books is that they contain a little bit of the
personality of the authors in them. That is also why I begin the
chapters with quotes from philosophers. By including examples from my
music tastes, I am adding a bit of my personality to the book. And
there is nothing offensive in any of these titles. In fact, they should be familiar to most of my audience, especially those with even a passing familiarity with Punk, New Wave, Industrial, and Alternative rock.
The Cure's Pornography is universally
acclaimed as the Cure's most important work. And the Cure is one of the
most influential bands to modern rock, pop and alternative. Though,
admittedly, modern pop is more influenced by Disintegration and
Wish than Pornography.
Garbage, on the other hand, is a very
popular modern band. One of their song's is the theme to the James Bond
movie The World Is Not Enough.
On a final note, I have included this CD example in both editions of
Database Programming with JDBC and Java and the only negative comment
I have ever heard was from a professional reviewer rightfully complaining about me
misspelling the name of the Sex Pistols album.
I hope this response clears up some confusion.
George
|
