"David M. Karr" wrote:
>
> In an experimental application I'm building, I have two entities, named
> "Student" and "Class" (no name conflict, I use "ClassBean", "ClassHome", etc.).
>
> I also have an entity named "StudentClassGrade". This essentially reflects a
> "valued association", referencing a Student and Class, and containing a Grade
> value.
>
> My first question is, what should be the types of the "Student" and "Class"
> references in "StudentClassGrade" be? Should they be the remote references, or
> the primary keys? The primary keys of "Student" and "Class" are, respectively,
> "String ssn" and "String name".
You would be ill-advised to use remote references because this would make it
impossible to use the database other than via EJB, and would break the database
when you moved from one server to another (and perhaps even when you upgraded to
a new release).
> Then, dependent on that, my PK class for "StudentClassGrade" will be a compound
> key. I'm fairly certain this should contain the two primary keys of the
> associated Student and Class, but I'm not quite sure how this should work.
You StudentClassGrade DB table would contain both columns and the database would
understand that together they constitute a unique key. Your EJB would contain
both fields and a separate PK class would allow the container to treat the key
as a single object.
> I'm having a lot of trouble finding good documentation and examples for this
> sort of thing. I've found umpteen examples of trivial beans and PKs, but
> nothing like this. I was hoping the new "Professional EJB" book would cover
> this well, but it doesn't.
Traditional relational database theory would probably lead you to the design you
have suggested, using socialSecurityNumber, className and
socialSecurityNumber+className as the PKs for your three tables. But modern
application design, which compromises the purity of the relational model to take
more account of futureproofing the database and of object-oriented programming
would probably lead you to something different...
Future-proofing:
1. How good is SocialSecurityNumber as a PK in the long term? It is (for
example) only a good key for US residents. I happen to have a ssn (because I
lived 6 years in the US) but most British citizens don't!
2. What about resits? At least you should probably include the year in the
StudentClassGrade PK in case resits are permitted in the future.
3. Are you sure that classnames are a good PK? Maybe "English" this year will be
called "Modern English" next. Not relevant for what you want to do with the data
today perhaps, but such changes would make it very difficult in the future to
follow trends.
Object-orientation:
1. PKs become de-facto Object IDs for OO applications, but OIDs that have
meaning in the application domain create restrictions. For example they become
immutable attributes.
2. Relational databases work in terms of selects and joins, but OO applications
work in terms of navigation from object to object. Both have their place and
your persisted data needs to support both well. Even if all programming is
object-oriented, the relational calculus makes it posible to materialise data
into a completely different set of objects than were conceived of when the
database was designed (e.g navigating objects to generate a set of resit objects
might take hours, whereas a simple SQL query might generate the data in seconds)
More on IDs:
1. Concepts like "StudentID", "classID" are usually short human-friendly
numbers. Because the numbers are short, they are taken from a reusable pool and
recycled when necessary. Such IDs are not suitable for use as Object IDs, which
should be long enough to never have to be reused.
2. Concepts such as invoice number usually have to be monotonically increasing
in the short term, but the sequence can be restarted. They are only guaranteed
unique within an accounting period.
3. Both of the above types of ID need to acquire database locks of some kind to
acquire, creating inherent *application* design considerations of concurrency
and clusterability.
4. OIDs don't need to be short, but they do need a guarantee of uniqueness over
a (very) long period of time, and should not require acquisition of database
locks to obtain them.
This makes OID allocation an "interesting" problem which SHOULD be handled by
*middleware* but which so far does not have a standardized interface, let alone
any widely available implementations.
To the application the OID is opaque, but its private fields should be something
like:
- name of the generator implementation (eg com.alexissystems.java.oidgen)
- locally unique name of the computer (e.g. IP address)
- ID of generator instance on the computer (e.g. process id)
- timestamp down to a few seconds
- short number providing the final level of uniqueness when all of the above are
the same.
Ooops, I seem to have gone on rather a lot! Hope it's what you were looking for.
cheers... Ian
========================================
Ian McCallion
Alexis Systems Limited
Romsey, UK
Tel: +44 1794 514883
Fax: +44 1794 501692
========================================
===========================================================================
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".
