So this boils down to the question "what makes a Statement unique?"
As John Q pointed out (and Seth noted in his question based on Hal's
newsletter), an object should not be dependent on its persistence
mechanism in terms of its properties.
But Seth said the Statement doesn't know enough about itself to be
uniquely identified. This suggests that some sort of identifier is
needed within the object, so an instance can be identified. Call it
StatementNumber. (An object must be able to tell itself from another
object of the same class.)
The database (regardless of whether it's a flat file, RDBMS, or object
DB) would store StatementNumber as part of its job of persisting a
Statement. Does the database also have an ID field that uniquely
identifies a record in, say, a Statements table? That depends on the
database implementation, NOT the application. In an RDBMS, it might
take 2 or 3 (or more) tables to efficiently store whatever data
comprises one Statement. Depending on the nature of the StatementNumber
datapoint, it might make more sense to use an internal ID field (which
is never exposed to the application) to manage these relationships. An
OODB would take a completely different approach. The application
shouldn't know or care which one you use.
- Jeff
Bill Rawlinson wrote:
Valid points Seth - but if you can't do the job without using the ID
then I think the statement needs to know about the ID and so does
everything else.
Since you mentioned his name I'd love to hear if Hal has a different
suggestion. But if using the db ID is wrong then I'm almost always
wrong :O)
Bill
On 11/14/05, Seth Johnson (KW) <[EMAIL PROTECTED]> wrote:
There may be another way to uniquely identify a
statement by combining two or more fields. If
that's the case you probably have a "candidate key"
in your database that your DAO could use.
Nope, no combination of fields form a natural key, which is why I went
the route of the identity field.
My concern wasn't about using the ID field as a key, but more about what
objects were made aware of that key. Everything I've read on proper
software engineering (including this list) promotes decoupling the
object's internal representation from how it is persisted. That made me
question my design, since the statement ID was created _based on_ how it
would be implemented by the database.
In other words, my system includes an auto-incrementing PK because
that's what the database supported, not because any particular
specification in the problem domain. This made me question whether or
not that approach was a good idea when I refactored to an OO design.
This whole thing started when I read Hal's "Applied Ontology" newsletter
(http://www.halhelms.com/index.cfm?fuseaction=newsletters.show&issue=123
104_ontology). Following his advice I tried thinking about Statements
in terms of "if I'm a statement, what do I know about myself?" When I
did that, I discovered that a Statement ID value has no meaning to the
statement itself, only to the persistence layer.
That's when I got confused, since the ID is necessary for the system to
identify statements, even if individual statements don't need to know
how it happens.
Thanks for the comments so far,
Seth
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
--
[EMAIL PROTECTED]
http://blog.rawlinson.us
If you want Gmail - just ask.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
