A high level approach I take when doing data mapping is to have a set of objects that acts as an intermediary between my in memory objects and my non-OO data. THis way, the rest of my system thinks it is dealing with an OO database, even though it is not. These layering objects are factories on one hand, creating objects from the database and updaters (for want of a better
word) that move objects I need persisted into the rdbms. These layers aren't all that hard and are easy to maintain. It also allows me to write query objects that can work directly on the RDBMS. Relational databases have some really strong advantages if you don't need to worry about differences of the objects. For example, some applications I've worked on have had to worry about different nationalities. In my code, I'd use
polymorphism to hide differences in tax rules, ... However, my databases typically could be easily split up so only data from one country was in any one data base. This allows for quick queries and extractions to be done in the RDBMS itself.
------------------
Alan Shalloway,
Look for Jim Trott and my book:
Design Patterns Explained Visit our site
Net Objectives.
Visit our
on-line companion to the book
Alan Shalloway.<BR>Look for Jim Trott and my book: <A HREF="http://www.amazon.com/exec/obidos/ASIN/0201715945/ref=ase_electricporkchop/103-0514572-3811868" TARGET=_blank rel="nofollow">Design Patterns Explained</A><BR>Visit our site <A HREF="http://www.netobjectives.com" TARGET=_blank rel="nofollow">Net Objectives</A>.<BR>Visit our <A HREF="http://www.netobjectives.com/dpexplained/index.html" TARGET=_blank rel="nofollow">Design Patterns Explained Community of Practice</A><BR>Check out our <A HREF="http://www.netobjectives.com/xml/xml_cdrom_info.htm" TARGET=_blank rel="nofollow">CDROM based audio training in XML</A>