View Single Post
  #30  
Old September 26th, 2005, 05:03 PM
BruceM
external usenet poster
 
Posts: n/a
Default

"I do not rely on front end applications to enforce data integrity and would
strongly discourage such development. If I have a business rule which Jet
cannot enforce via constraints then I would recommend porting to MSDE."

I really don't know what you mean by "porting to MSDE". I found out what
MSDE is, but for my purposes I will find a way to validate the data, whether
at the table level or in the front end. You can strongly discourage using
the front end for such purposes, but have not provided a reason why. If
there is a Spouse First Name field it may be required if the person is
married, but certainly not otherwise. My choice is the front end for such
validation rather than another piece of software. Before Update works for
my purposes. I will continue to use it. Data integrity is not compromised.
The database works smoothly and quickly. If it is "inefficient" it is so on
a level that is not important to me.

"Miss N E Person ID=1 of Main Street and Miss N E Person ID=2 of Main Street
are different people". Then I will figure out a way of telling them apart
that is useful to the person who needs to call or contact one or the other.
Knowing that they are different records in the database (because they have
different ID numbers) is not helpful in telling them apart.

wrote in message
oups.com...

BruceM wrote:
I think I understand that your PK and your field(s) on the one side of
one-to-many may not be the same. If so, and if the PK is not part of a
relationship, would the purpose of your PK be to guard against
duplication?


No, it would be the 'field(s) on the one side of one-to-many' that
would guard against duplication. The purpose of the PK would be to
avoid a performance-degrading clustered index and, if possible, to
provide for a performance-enhancing clustered index.

If so, do you regard that as a more efficient use of recources than data
validation code in the form's Before Update event?


I do not rely on front end applications to enforce data integrity and
would strongly discourage such development. If I have a business rule
which Jet cannot enforce via constraints then I would recommend porting
to MSDE. For me, 'efficiency' doesn't come anything close to data
integrity in terms of importance.

Also, if by "expose it" (in reference to an artificial key) you mean show
it
to the user, why would that be necessary?


You know Miss N E Person ID=1 of Main Street and Miss N E Person ID=2
of Main Street are different people, but when you speak to one of them
on the phone, how do *they* tell you which one they are?