Re: Separate PK in Jxn Tbl?

From: James A. Fortune <>
Date: Sun, 27 Jan 2008 17:20:08 -0500
Message-ID: <uG9eTMTYIHA.4448_at_TK2MSFTNGP03.phx.gbl>

David Cressey wrote:
> "Brian Selzer" <> wrote in message
> news:MOUmj.1465$

>>Well, that's just dumb.  Checks in code can reduce database round-trips,

> and
>>therefore can improve performance, but are not and cannot be a substitute
>>for constraints on the tables.  It is the constraints on the tables that
>>keeps garbage out of the database.

> The idea of keeping garbage out of the database takes on an entirely
> different meaning if you are dealing with hundreds of programs written in
> COBOL, Java, or anything in between accessing a single Oracle database on
> the one hand. On the other hand, if you are a developer creating a self
> contained MS Access database cum application (tables, queries, forms,
> reports, modules, etc.) all in one file, the same issues arise, but they
> are resolved quite differently.
> I'm not saying either one is "right" or "wrong". I'm just suggesting why an
> objection that makes perfect sense to you and me might be lost on the MS
> Access community.

I am only speaking for myself. I may be the only Access programmer on the planet who validates input the way I do in code. I am not unaware of the desirability of enforcing constraints at the table level. My reluctance to depend on error trapping is shared by very few, if any, Access developers. Those who judge my unorthodox style choices as ignorant or incorrect presume much.

For example, in "Joe Celko's SQL PROGRAMMING STYLE:

Q: Couldn't a natural compound key become very long?

A1: So what? This is the 21st century, and we have much better computers than we did in the 1950s when key size was a real physical issue. What is funny to me is the number of idiots who replace a natural two- or three- integer compound key with a huge GUID, which no human being or other system can possibly understand, because they think it will be faster and easy to program.


The auto-numbering features are a holdover from the early SQLs, which were based on contiguous storage file systems. The data was kept in physically contiguous disk pages, in physically contiguous rows, made up of physically contiguous columns. In short, just like a deck of punchcards or a magnetic tape. Most programmers still carry that mental model, too.

The most pathetic part is that many here even parrot his (incorrect) reasoning about my reasoning. I submit that they, not I, are succumbing to subtle psychological effects.

James A. Fortune Received on Sun Jan 27 2008 - 23:20:08 CET

Original text of this message