That's a bit of a rat's nest you're opening there and cannot possibly be answered in a PM node (just type "object-relational impedance mismatch" into Google and read some of the 25,200 articles that come up to get an idea). I'll stick to your last question and answer that with a resounding "probably no". The rules of database normalisation are very different from those of good OO design. You want to organise your objects much more according to the business logic of your application, the whole point of objects is to expose an interface which makes them easy to work with. Database normalisation doesn't particularly care about interfaces, it is about organising the data in the most efficient way possible.
As an example, supposed you have a database of people containing a name and telephone number. Unless every person has exactly one telephone number (and vice versa) you'll want to keep telephone numbers in a separate table and match the two records with a common id. Your person object OTOH can contain all the telephone numbers associated with this person. Now, if the phone number is something that you'll want to manipulate often (for example if you're a telco and you need to associate phone numbers with phone exchanges, look up number of minutes this number has been in use for the last month etc.) then it may make sense to create a separate phone number class, which contains the necessary methods and data. But if all you're ever going to do is set and retrieve the phone number you don't want to do that, the overhead of writing and instantiating a class for a simple string lookup is wasted effort. (Unless you're programming in Java of course ;-).
Hope that helps.
In reply to Re: OO design and persistence
by tirwhan
in thread OO design and persistence
by jimbus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |