I don't know why I called you "Tony". It's been a long day and I'm just getting started...
M!ke -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dawson, Michael Sent: Monday, September 19, 2005 9:03 AM To: [email protected] Subject: RE: [CFCDev] Table joins DAOs Tony this was a very good example to clarify some issues I have been dealing with. BTW, who makes the Fairy Dust storage system? We are looking at getting a SAN, but FD takes much less physical space than a SAN. Thanks -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RADEMAKERS Tanguy Sent: Monday, September 19, 2005 7:46 AM To: [email protected] Subject: RE: [CFCDev] Table joins DAOs Hello Nick, Given your answers you are looking at one DAO - the UserDAO - which will hit three (or however many) tables to persist your User object. In terms of pseudo-code... it will probably look much like your existing handler code for that form: a number of insert or update queries - some of them in a loop - in a cftransaction block. If you had answered that other entities in your system had contract or employment info, then you would have needed separate DAOs for those elements. Otherwise, you would have had insert/update sql for those tables spread across two (or more) .cfc files - a sure sign that something was wrong (or at least headed that way). Let's take another example: an address. Let's say a user has an address, a company has an address, and an order has two addresses (shipping and billing). It wouldn't make any kind of sense to have four different insert and update statements hitting one table and living in three different cfc files - you'd want a single AddressDAO with one insert and one update statement. You have to think of it this way: the number and layout of database tables used to store an entity's data (in this case a user) is just an implementation detail. Once you've hidden this behind a dao then you'll probably never have to worry about it again. That's one of the major points behind using daos: it could be one big table, it could be twenty little tables, it could be a magical fairy dust powered storage system - you don't care, you just call the save method on the dao. /t >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Nick Han >Sent: Friday, September 16, 2005 7:14 PM >To: [email protected] >Subject: RE: [CFCDev] Table joins DAOs > >>two quick questions: > >>1) Do you think of that form as the "user edit form"? Or do you think >of it >as the "user, contact, and employment edit form"? >>2) Are there other things in your app that *also* have contact info >and/or >employment info, but are not users? > >Tanguy, > Having read other people's emails this morning about this topic, I >think I know where you are heading with these questions. But I am >interested to hearing your take. > >Ok, > >For question #1, let's say I think of the form as "user edit form". >This edit form has user's login info (like username and password in the >users table), has user's contact info (like work address, home address, >emergency address in the contact table), and has employment info. So >upon this edit action, the update will hit all three tables. Given this >scenario, how would I set up my DAO(s)? One DAO that does all this? >Give me some pseudo code to look at. > >For question #2, let's say the users table is the parent table, and no >contract info or employment info will exist without having a relational >id to the users table. (1 users record to one or many contacts or >employment info). > >Thanks in advance for your input. > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of RADEMAKERS Tanguy >Sent: Thursday, September 15, 2005 12:19 PM >To: [email protected] >Subject: RE: [CFCDev] Table joins DAOs > >>Barney, can you reduce the language down like a fraction so I can >>understand better on what you just said? Ok, for a DAO >example, I have >>a form that will insert information about the user into users table, >>contacts table, and employment table? Will I have one DAO to do all >>this or 3 separate DAOs, one for each table? It sounds like what you >>said is that there should only be one DAO? Thanks in advance. > >two quick questions: > >1) Do you think of that form as the "user edit form"? Or do you think >of it as the "user, contact, and employment edit form"? >2) Are there other things in your app that *also* have contact info >and/or employment info, but are not users? > >/t > > >---------------------------------------------------------- >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). > >CFCDev is supported by New Atlanta, makers of BlueDragon >http://www.newatlanta.com/products/bluedragon/index.cfm > >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). > >CFCDev is supported by New Atlanta, makers of BlueDragon >http://www.newatlanta.com/products/bluedragon/index.cfm > >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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
