You're mixing two metaphors and will run into troubles, just accept
that relational databases are not an inherited object model.
But to answer your question consider the following:
table PetType:
int id
string name
int number_of_legs
table Pet
int id
int type_id // foreign key of PetType
is roughly equivalent to:
class Pet {
virtual int NumLegs() = 0;
protected:
int id;
int number_of_legs;
}
class Bird : public Pet {
int NumLegs() { return 2; }
}
class Lizard : public Pet {
int NumLegs() { return 4; }
}
select id from pet, pettype where pet.type_id = pettype.id and
pettype.num_of_legs = 4;
When you have a table with a foreign key then that table is kinda like
an abstract base type. Now just put a table in between pettype and pet
for your many-to-many but the principle is the same.
Kurt
On 2009-10-16, at 12:17 PM, Chip Grandits wrote:
>
> I am fairly new to Django. I have a strong background in object
> oriented design, but only a shallow familiarity with relational
> database design. I am trying to develop my models and I have a sort
> of general philosophical question about what the ORM is capable of,
> and how it should be used.
>
> So lets say, for example you are designing a website for a network of
> people who take care of pets. The caretaker would have a many-to-many
> relationship with pets, since one caretaker could take of more than
> one pet, and one pet might very well have more than one caretaker. Of
> course pet is an abstract class - and we can easily imagine many
> concrete derived classes such as dog, cat, fish, snake, ferret, etc.
> These derived classes have much in common but seem to have enough
> distinction that they each have some attributes that makes it seem bad
> design to "munge" them all into a general concrete pet class.
>
> I am not clear if the the philosophy of the Django models is meant to
> allow a model to have a many-to-many relationship with an abstract
> base class. To help me understand, I read several time in books and
> online docs about how an explicit 'through' table works as the
> intermediary for a many to many relationship. But I cannot get my
> head around how this would actually work for an abstract base class in
> the relational database. It seems that the intermediate table might
> have a column (or multiple columns) with primary keys, but it would be
> the primary keys of different tables for the different base classes.
> To use my example, a table representing a "Caretaking Relation", would
> have a column with a primary key to the Caretaker table, and another
> column (or multiple columns) with primary keys to the various tables
> that are the subclasses of pet, i.e. the dog table, the cat table, the
> snake table, the fish table, etc. And I guess I am not comfortable
> that this idea really works. Will the manager classes "get confused"
> about which table the foreign keys refer to? I guess I'm worried that
> it might actually produce code that runs without producing errors, but
> leads me into a morass of problems down the road.
>
> So perhaps there is a good link someone can point me to? Or perhaps
> just a reassurance that this is an effective technique? Or a warning
> that it depends upon the particular database engine? Or advice on
> some coding and design that needs to be done to avoid problems (e.g.
> Maybe I have to somehow make sure that the primary keys for the
> derived class tables are unique among all the derived class tables)?
> Or perhaps just a statement that such a design does not map well from
> object oriented code to relational databases and I should use a
> different design strategy?
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
