Re: Displaying Primary Keys
Re: Displaying Primary Keys
- Subject: Re: Displaying Primary Keys
- From: Pierre Frisch <email@hidden>
- Date: Fri, 26 Dec 2003 23:28:03 -0800
In my experience it all depends what you are doing i.e. retrofitting an
existing database or creating a new application with a new database. In
the later case I would go for using the database as an object store.
Make the primary key totally meaningless using a unique scheme for
generating the PK in the application and never displaying it. That way
you don't need a trip to the database to create it. Apple provides a
mechanism for generating 24 bytes PK that are guaranteed to be unique
in the know universe. All my application use a derived scheme where the
primary key is a string that combine the 24 bytes unique key with the
name of the entity. This enable the optimization of relationships when
using multi-tables inheritance.
The issue here is whether your database is used by human using sql or
through custom written application. In the first case you may need some
more humanly manageable key on the later case having opaque key has a
big advantage in speed and cost of maintenance. With WebObjects
building small admin application with Direct to Web is cost effective
so I would need a lot of convincing to go for the first approach.
Pierre
On Dec 26, 2003, at 13:11, Chuck Hill wrote:
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.
_______________________________________________
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.