If you re-read what I wrote, I think you'll agree we're saying the same thing.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hal Helms Sent: Tuesday, November 15, 2005 5:20 PM To: [email protected] Subject: RE: [CFCDev] Who owns the "ID"? Q, the objectID does not have to be the primary key of a table. In fact, for joining purposes, I often have a number as the PK/FK of the database but use the objectID as part of the WHERE clause. I guess what I'm saying is that with a system that can return a unique objectID, you don't need to also track primary keys in the object itself so long as the *database* stores the objectID as well as any PK/FK stuff it needs. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Quarto-vonTivadar Sent: Monday, November 14, 2005 12:14 PM To: [email protected] Subject: RE: [CFCDev] Who owns the "ID"? You could just have a StatementID for DB purposes ("the key, the whole key, and nothing but the key"), and a ObjectID for each record (unique, of course), for anything outside the DB that needs to uniquely identify a Business Object, since of course there should be no way for those outside requests to know that the Business Object is stored as a single record in a single table, or spread across multiple tables or etc. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Johnson (KW) Sent: Monday, November 14, 2005 11:11 AM To: [email protected] Subject: [CFCDev] Who owns the "ID"? Hey all, I've been lurking here for awhile as I make my transition from a procedural coder to an OO designer. So far this list has been very helpful, I've even learned things from the flame wars :) I'm currently refactoring a royalties management system into a OO/CFC based system and I have a question about where in the object hierarchy I should stick primary key ID fields. For example, my system will have a Statement object that represents an accounting statement for a publisher. The data for statements is stored in a database using a "StatementID" PK to uniquely identify each row. But since the StatementID is only a persistence mechanism, and has no "business use" other than uniquely identifying a database row, does it belong in the Statement object? Or should it only be used by DAOs and gateways that are tied to a specific database implementation? (And if it is only of use to DAOs, how do I pass it around my app without tightly coupling myself to that specific database implementation?) For all practical purposes this app will never need to replace the PK identity column with a GUID or other key, and it really doesn't hurt me to throw the ID into the Statement object. But I'd still like to know if there is a better way. Any suggestions or comments would be appreciated! Regards, Seth Petry-Johnson ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
