I would usually approach this kind of thing by having one Article table with
an ArticleType column that would specify what type of article and then all
of the other fields you need for any type of article.
Yes, that's a possibility too (and can be very appropriate in some circumstances).
So the JornalName column would only be used with an ArticleType of "Journal"
or 2 or whatever, and it would be blank with the other types.
And it doesn't change the DAO objects you would need - you'd still have an ArticleDAO(**) and a JournalArticleDAO - they would just do different things (JournalArticleDAO would just save the snapshot of the JournalArticleBO to the Article table).
** Note that if you have a base class for a generic "thing" and extend it for specific "thing"s, you might not really have persistence for the base class. If ArticleBO is generic, you probably don't have ArticleBO instances so you *probably* don't need an ArticleDAO since there won't be anything to persist!
As a general point, when you're talking about inheritance and persistence, you need to think about whether your base class is abstract or concrete (concrete classes persist, abstract classes don't). In the real world, concrete *base* classes are pretty rare.
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive." -- Margaret Atwood
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
