I think having a general objectID, implemented in a BaseComponent, is a more generalized solution, Jeff.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Peters Sent: Monday, November 14, 2005 2:28 PM To: [email protected] Subject: Re: [CFCDev] Who owns the "ID"? 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] ---------------------------------------------------------- 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]
