Django: Object Oriented or Relational Database?

968 views
Skip to first unread message

Adrian Bool

unread,
Jan 26, 2011, 6:41:10 AM1/26/11
to django...@googlegroups.com

Hi,

I'm creating a DB using Django for managing our companies data - customers, services, orders, billing etc. I'm using the Django admin interface to manage the data.

I seem to be consistently at odds with myself and would be good to hear the community's point of view on this.

I'm defining the DB in Python; using objects and inheritance. As such, when I'm doing this I'm thinking in an object orientated (OO) manner - a service uses a number of resources so I create a Service object with with either foreign key or many-to-many (as appropriate) relationship to the Resource objects. This gives me nice referential integrity and I can be sure that the Service has valid connections to the Resources it requires.

It seems, however, that Django expects the models not to be defined in an OO manner. For example; should I wish resources to be listed as Inlines on the Service's page I can only do this if the foreign key is with the Resource - pointing 'up' the stack to the services - as possible to being pointed to by the Service. Django seems to be defining stricture using an OO language; but expecting that structure in a more traditional, relational database, style where entries point up to their owners rather than the owners pointing down to their children.

In order to try to fit in with Django Admin I've ended up using both styles. Unsurprisingly this mixture of styles is now causing me problems with circular dependencies. I know I need to jump one way or the other; but would be great to get some comments from experienced Django coders before I decide which way...

Any comments/advice welcome...

Cheers,

aid

Daniel Roseman

unread,
Jan 26, 2011, 6:55:32 AM1/26/11
to django...@googlegroups.com
This is what's known as the object-relational impedance mismatch [1]. Unfortunately, as you've noticed, OO concepts don't map completely cleanly onto the relational model, and this is an issue with all systems that attempt to do it. Django does what it can to smooth over the gaps, but can't always do everything.

However, you should not be getting circular dependencies. Can you provide some examples? One place where I often see them is when two models in separate applications are related via ForeignKey, and the developer has imported each model into the other's models.py. But it isn't necessary to import them at all, as you can refer to models via strings: 

    myfkfield = models.ForeignKey('otherapp.OtherModel')

so no circular dependency is declared. Does that solve your problem? If not, some examples will be helpful.
--
DR.

Adrian Bool

unread,
Jan 26, 2011, 7:12:52 AM1/26/11
to django...@googlegroups.com
On 26 Jan 2011, at 11:55, Daniel Roseman wrote:

This is what's known as the object-relational impedance mismatch [1]. Unfortunately, as you've noticed, OO concepts don't map completely cleanly onto the relational model, and this is an issue with all systems that attempt to do it. Django does what it can to smooth over the gaps, but can't always do everything.

Thanks for the link; interesting reading.

However, you should not be getting circular dependencies. Can you provide some examples? One place where I often see them is when two models in separate applications are related via ForeignKey, and the developer has imported each model into the other's models.py. But it isn't necessary to import them at all, as you can refer to models via strings: 

    myfkfield = models.ForeignKey('otherapp.OtherModel')

so no circular dependency is declared. Does that solve your problem? If not, some examples will be helpful.


I've used the string form for forward references of models; but I still seem to get problems when performing the initial migration (using South) of the database as the table to which the forward reference points does not exist at the time of creating the initial table.

I've just tried using a basic syncdb and that works fine.  I presume I'm seeing problems as South's migrations work one app at a time; in contrast to syncdb that seems to install the whole project - only worrying about dependencies at the end.

Still; I feel circular dependencies are bad; even work arounds are possible.

Is there a recommended path to take with Django?

Kind regards,

aid



bruno desthuilliers

unread,
Jan 26, 2011, 7:55:58 AM1/26/11
to Django users
On 26 jan, 12:41, Adrian Bool <a...@logic.org.uk> wrote:
>
> I'm defining the DB in Python; using objects and inheritance.  As such, when I'm doing this I'm thinking in an object orientated (OO) manner - a service uses a number of resources so I create a Service object with with either foreign key or many-to-many (as appropriate) relationship to the Resource objects.  This gives me nice referential integrity and I can be sure that the Service has valid connections to the Resources it requires.
>
> It seems, however, that Django expects the models not to be defined in an OO manner.  For example; should I wish resources to be listed as Inlines on the Service's page  I can only do this if the foreign key is with the Resource - pointing 'up' the stack to the services - as possible to being pointed to by the Service.  Django seems to be defining stricture using an OO language; but expecting that structure in a more traditional, relational database, style where entries point up to their owners rather than the owners pointing down to their children.

That's indeed how a relational DB works, and Django's ORM doesn't try
to pretend the relational DB doesn't exists or is just a dumb 'bit
bucket'. So, while models ares defined as classes, these are mostly -
from this POV at least - "technical" objects wrapping the relational
model, and not "pure" OO domain objects (whatever a "pure" OO domain
object might be). This doesn't mean you have to go for an "anemic
domain model" neither - your relational schema is part of the "domain
space", and models (as well as managers) are also here to support
additional responsabilitie.

Some will talk about "OO/relational impedance mismatch" (ok, I cheated
- Daniel just did;)), but I don't see it that way as far as I'm
concerned - I'm using a relational model wrapped into an OO
representation, and that's just what I want for most apps.

Adrian Bool

unread,
Jan 26, 2011, 4:30:40 PM1/26/11
to django...@googlegroups.com

Hi Bruno,

On 26 Jan 2011, at 12:55, bruno desthuilliers wrote:
> Some will talk about "OO/relational impedance mismatch" (ok, I cheated
> - Daniel just did;)), but I don't see it that way as far as I'm
> concerned - I'm using a relational model wrapped into an OO
> representation, and that's just what I want for most apps.

Many thanks for your comments; although it wasn't really what I wanted to hear - as I prefer the OO model over the relational. I now feel that if I decide to use Django - not following a relational style will only cause me difficulties.

Kind regards,

aid

bruno desthuilliers

unread,
Jan 27, 2011, 8:43:28 AM1/27/11
to Django users
You are of course free to replace Django's ORM with some OODB (ZODB
anyone ?), but then say goodbye to the admin.

But anyway: for the kind of apps/tasks you described, nothing beats a
good relational DB. Really. Been here, done that...

Reply all
Reply to author
Forward
0 new messages