> 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]
