Re: Problems using primary key as attribute
Re: Problems using primary key as attribute
- Subject: Re: Problems using primary key as attribute
- From: Pam Niedermayer <email@hidden>
- Date: Sat, 16 Aug 2003 19:23:41 -0500
- Organization: Pinehill Softworks Inc
OK, then what happens when the client # is changed, which is definitely
possible for any number of reasons? If you have a separate key, you can
make the changes without blinking.
Pam
Ray Ackland wrote:
I don't know if I would go along with such a strong critique. All they
are doing is using the primary key in a relationship with a real life
filing cabinet. This just means that the key need to be human readable
(or get the computer to go to the filing cabinet for them :).
The only knowledge contained in the client # is what record to look up
(in the cabinet) which is what is the norm.
r.
On Sunday, Aug 17, 2003, at 02:41 Pacific/Auckland, Pam Niedermayer wrote:
This is abysmal database programming, no doubt picked up from using
Filemaker for years. Normalization heuristics say your primary key
should not contain knowledge, should just be a stand alone key.
Pam
Ray Ackland wrote:
My customers have a FMP system (that I am converting to WO) where
the client # is used to match the (physical) file in their filing
system. As a result, I am wanting to use the client # as a primary
key as well as making it a class property.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.