Re: Displaying Primary Keys
Re: Displaying Primary Keys
- Subject: Re: Displaying Primary Keys
- From: Chuck Hill <email@hidden>
- Date: Fri, 26 Dec 2003 13:11:03 -0800
FWIW,
"for nearly all purposes, meaningless" != "meaningless"
Why should an administrator care if it is an integer or a binary key or
whatever that is used to form db relationships? That is implementation.
Meaningful data can change. If relationships are formed on the data,
rather than the underlying meaning, updates to key are problematic at best.
If "10" and "Visa Credit Card" both have meaning to the admin then you
should choose another PK.
IMHO,
Chuck
At 03:48 PM 26/12/2003 -0500, Drew Thoeni wrote:
>Chuck (and others),
>
>Your answers have proved very helpful. To more clearly state this, I'm
>not using the primary key as a piece of real data. It is, for nearly
>all purposes, meaningless. However, for administrative purposes, being
>the unique identifier of a row, the primary key creates its own
>meaning. For example, code tables that support the other tables. My
>PaymentMethodCode table, which has a short description of the payment
>types also, of course, has a primary key which, in this case, is
>paymentMethodCodeId. On administrative pages, it is helpful to identify
>these by their primary key and description (e.g. 10, Visa Credit
>Card).
>
>For users, (and only for admin purposes) it is handy to have the
>primary key display to ensure the administrator is dealing with the
>right John Johnson. (e.g. 342568, John Johnson).
>
>So, speaking from a relational table point of view (where I have more
>experience than WO), I agree with both schools. Nearly always I make
>the PK meaningless. It is handy to know that WO does not require that
>PKs not be part of the class.
>
>Regards,
>
>Drew
>
>On Dec 26, 2003, at 2:47 PM, Chuck Hill wrote:
>
>> Drew,
>>
>> There is no need to exclude a primary key from the class in order to
>> have
>> EOF manage the relations. EOF simply removes the need to manage these
>> yourself.
>>
>> There are two schools of thought on this, one is wrong ;-) and the
>> other
>> maintains that primary key values should be meaningless. As
>> meaningless
>> values, there is never any need nor use to display them in the UI.
>> Thus,
>> the should not be included in the public (class) attributes in the
>> EOModel.
>>
>> If your userID is what the user types when they login, then it should
>> *not*
>> be the PK. Add another column to serve as the key. This way if a
>> userID
>> ever needs to be changed (e.g. for a legal name change, marriage,
>> whatever)
>> then the update can be made to the information (what the user types)
>> without affecting the validity of the relationships. A rose by any
>> other
>> name...
>>
>> Chuck
>>
>>
>> At 08:54 AM 26/12/2003 -0500, Drew Thoeni wrote:
>>> public void newbieProblem() {
>>> I read (and have found) that if I want to properly used object
>>> references between enterprise objects that I must not include the
>>> primary key in the class (i.e., I click the diamond off in EO
>>> Modeler).
>>> However, there are times I want to display the primary key. For
>>> example, in administration pages, I like to display the userID. Or
>>> when
>>> editing code tables, the primary key would be useful to display.
>>> }
>>>
>>> public Answer newbieQuestion() {
>>> What is the proper way to do this? Any references out there you
>>> suggest.
>>> }
>>> _______________________________________________
>>> 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.
>>>
>>
>> --
>>
>> Chuck Hill email@hidden
>> Global Village Consulting Inc.
>> http://www.global-village.net
>>
>
>
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
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.