On 05/14/2011 06:50 PM, bendavis78 wrote:
The right answer depends on what you are actually going to need to do with the data.I have a database of patients ("Patient" model), and a patient can have subordinate accounts which is a self-foreign-key (eg, for family members), We also store multiple addresses for each patient (home, work, billing). I'm pretty sure I need to have an Address model as a many-to-one, because a patient can have multiple addresses. But, I'm also thinking of going one more step and making it a many-to-many, because multiple patients (eg, a family) can share the same address. Am I over-normalizing if I do this? It seems that it would make editing via the admin a bit more difficult, however the data would not be duplicated. Is there a good rule-of-thumb for these kind of design decisions?
I think that it's better not to have multiple people share the same address, for the simple reason that one of them may move, or change something about the address which would affect the others.
There might be a decent case for storing relationships so that, for example, you know that people are related.
Also, if you expect to be doing much with many-to-many relationships, definitely check out the docs for instructions on how to define your own relationship tables so you can store additional data that really doesn't belong elsewhere.
http://docs.djangoproject.com/en/1.3/topics/db/models/#extra-fields-on-many-to-many-relationships Shawn -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
