> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tinou Bao
> if your primary key is not a compound key but just a simple int or long is
> there any reason to define your own pk class instead of just using the
> String class or Long class? does it have anything to do with how well the
> hashcode is distributed?
No, since typically, if your PK class is a simple wrapper over a long, you
will return this value as your hashCode.
The following arguments can be said for user classes as primary keys:
- they make it easier to move to a compound primary key implementation if
one day, you decide you need it (less search/replace through your code, and
you are already using real objects instead of primitive ones, i.e. calling
equals() for comparison, etc...)
- they represent an overhead compared to primitive types
For primitive types as primary keys, just reverse those points.
My recommendation? Premature optimization is the root of all evil: start
with a user primary key class, even if all it does is wrap a primitive type.
Revert to a primitive type if ever you find out after careful profiling that
it is causing a big slow down in your application. Chances of that
happening are very slim, though, you will find that there are a lot of other
factors that need to be taken care of first.
--
Cedric
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
