>>>>> "Ian" == Ian McCallion <[EMAIL PROTECTED]> writes:
Ian> "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".
Ian> You would be ill-advised to use remote references because this would make it
Ian> impossible to use the database other than via EJB, and would break the
database
Ian> when you moved from one server to another (and perhaps even when you upgraded
to
Ian> a new release).
Could you elaborate on this? I don't understand these points.
I'll respond to some of these points in the context of pure application design,
but note that I'm just trying to develop a toy application that demonstrates
slightly more complex features than the usual EJB toy applications you run
into.
Ian> Future-proofing:
Ian> 1. How good is SocialSecurityNumber as a PK in the long term? It is (for
Ian> example) only a good key for US residents. I happen to have a ssn (because I
Ian> lived 6 years in the US) but most British citizens don't!
This is useful to know, but in the context of development of "real"
applications, they usually have a limited scope, unless you're really trying to
build a "component" that anyone can use. In particular, it's probably close to
impossible to build a "grading system" that can be plugged into any school
system in the world.
Ian> 2. What about resits? At least you should probably include the year in the
Ian> StudentClassGrade PK in case resits are permitted in the future.
Another example why it's impossible to build a truly general-purpose grading
system, as I don't even know what a "resit" is :) . I assume that's something
you see on your side of the pond.
Ian> 3. Are you sure that classnames are a good PK? Maybe "English" this year will
be
Ian> called "Modern English" next. Not relevant for what you want to do with the
data
Ian> today perhaps, but such changes would make it very difficult in the future to
Ian> follow trends.
When settling on a "primary key", I want to find something which won't change.
For this application, I don't want to introduce an auto-incrementing
world-unique opaque value generator. In particular, for my application, I
envision names like "eng101". That's good enough for this scope.
Ian> Object-orientation:
Ian> 2. Relational databases work in terms of selects and joins, but OO
applications
Ian> work in terms of navigation from object to object. Both have their place and
Ian> your persisted data needs to support both well. Even if all programming is
Ian> object-oriented, the relational calculus makes it posible to materialise data
Ian> into a completely different set of objects than were conceived of when the
Ian> database was designed (e.g navigating objects to generate a set of resit
objects
Ian> might take hours, whereas a simple SQL query might generate the data in
seconds)
This cuts to the core of the two opposing strategies: defining an application
around a database, or defining a database around an application. You want to
design an application around the database. I certainly agree with that. I've
seen too many "real" applications where too many people in power were "data
modelers" and wanted the application to be optimized and designed around the
database, instead of the other way around.
Again, since I'm just trying to illustrate and experiment with an end-to-end
J2EE application using security and relationships, this is irrelevant.
Ian> Ooops, I seem to have gone on rather a lot! Hope it's what you were looking
for.
Not even close :) , but still useful information.
--
===================================================================
David M. Karr ; Best Consulting
[EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)
===========================================================================
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".
