First, transactions are business logic, and if you've got business logic in your persistance layer, you've got problems. Transactions should be managed at the top of your business tier, because it's business rules that define what makes up an "atomic" action on the database.
Say we need to log business operations to a dedicated table in your museum example. In order to get that logging to happen in the transaction, you'd have to have your log stuff in EVERY DAO, which is clearly wrong, since you're logging business operations, not persistance operations. I.e. in your two-table update, we want to log one "museum info updated" operation, not two per-table operations. ...rant over... This is a perfect example of when the table/DAO ratio isn't 1:1. The purpose of persistance objects is to abstract the actual persistance mechanism from the application, so it's the ideal place to handle the dual-table nature of the storage. The winning phrase: "it makes senses to have a Dao that spans 2 seperate tables but represents it to the rest of the application as if it is 1 table." Your application just says "hey DAO, update this, would ya?", and the the DAO takes care of putting the right data in the right tables, without your application even knowing that there are two tables. Similar idea to updatable views in some ways, though in-code rather than in-db. So like everything else, the rule of thumb is one table per DAO. The trick is to understand what's going on well enough to know when to break the rules. And from the very concise example you provided, you've got it. ;) cheers, barneyb On 8/19/05, Peter Hardy <[EMAIL PROTECTED]> wrote: > Hi guys, > > I've been thinking about this for a few days now and although I can see why > people would say 1 table = 1 Dao, I'm not sure it's always the case. > > For Example, if you were building a Museum Guide application that had to > support multiple languages, you'd expect to have a Museum table somewhere. > However, in order to support an arbitrary number of languages, rather than > one table, you'd end up with two. One table would contain all the > language-neutral information and foriegn keys and the other would contain > all the language-specific information. I've included a sample schema below: > > Table Museum > > MuseumId Integer (PK), > MuseumName String, > MuseumOpenTime Time, > MuseumCloseTime Time, > MuseumPhoneNumber String, > MuseumTransport Integer (FK) > > Table MuseumDetails > > MuseumId Int (PK), (Matches MuseumId of Museum table) > MuseumDetailsLanguageCode String (PK), > MuseumDetailsSubject String, > MuseumDetailsShortDescription String, > MuseumDetailsLongDescription String > Note: This design allows us to add as many languages as we need but allows > only one instance of each language. > > As the data for a Museum is split across two tables, to Update one we'd need > to update both the Museum table and the MuseumDetails table and do so inside > a transaction so we could roll back if anything went wrong. ( i.e key > violation caused by duplicate LanguageCode in the MuseumDetails table). > > Now, if we follow the 1 table = 1 Dao mantra we'd have to handle our > transaction outside of our Dao's and that's doesn't make sense to me. > However, if we accept that our Museum is a single business entity, it makes > senses to have a Dao that spans 2 seperate tables but represents it to the > rest of the application as if it is 1 table. > > I'm not sure if this is a great example but it's the one in my head right > now and I'd love to hear other peoples views on the matter. It seems > sensible, I guess the question is, is it? :) > > Cheers, > > Peter (aka lad4bear) > > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 50 invites. ---------------------------------------------------------- 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]
