Re: Should (or can) you have many to many relationship with abstract base class

I had a dim memory about this and found this link
http://www.objectmatter.com/vbsf/docs/maptool/ormapping.html which
describes three
ways (which as I recall are the standard ways) to map an object
hierarchy onto relational tables.
None of the ways seem very pretty but as Kurt says there is what used to
be called "an impedance mismatch" between objects and relational databases.

-- peter

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 django-users@googlegroups.com
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---