OK, that clarifies what you were saying.
Regarding autonumber or other arbitrary PKs: If I have a listing of
vendors, what is the *unchanging* unique constraint? It is not name or
address in any combination, which are subject to change (thereby meaning
related records would also need to change). Maybe it could be the tax ID
number, but then you would need that information first, which is not always
practical. Or maybe it would be an arbitrary number in combination with
other fields that are not subject to change, such as...hmm.
Or maybe cascading updates of multi-field keys are not a problem. I would
rather avoid them, especially if another database links to that table.
You will not change my mind on the subject, nor I yours. But understand
that I *never* argued in favor or creating a table for which the "only
unique constraint is defined on a sole autonumber column". A record's
uniqueness is one thing. The means of identifying it in relationships is
another. The two may be the same, or they may not. I'm not going to bind
myself to an absolute rule based on somebody's design theory. Rather, I
will make the necessary choices as I go.

"Jamie Collins" wrote in message
ups.com...
On Aug 16, 3:19 pm, "BruceM" wrote:
If you don't have a problem with storing a calculation in a base table,
then
what is the normalization issue when it comes to queries? I doubt you
are
arguing against normalization in base tables, but where are you trying to
go
with this? How would you go about performing calculations? If the
results
are stored in a table, something can be done to force recalculation as
needed, but what does that gain you?

It's true, I'm not very strict about normalization in base tables,
ditto VIEWs. Quite strict, though, because I require a good reason and
assurance of data integrity. But equally strict because both are
tables. Usually I have no good reason, consequently I make it a stored
proc.

I think those who are very strict about normalization in base tables
should be very strict about normalization in virtual tables.

But you know me: I think every table (including VIEWs) should have an
enterprise key defined by business rules; if the only unique
constraint is defined on a sole autonumber column then I wouldn't
consider the object to be a table!

Jamie.

--