On Fri, 2006-08-04 at 10:28 -0600, Joseph Kocherhans wrote:
> On 8/4/06, Bjørn Stabell <[EMAIL PROTECTED]> wrote:
> >
> > Just a question; how does this compare pros and cons with single-table
> > inheritance, used in Rails? See:
> >
> > http://twelvelabs.com/singletable/index.html
You probably want to read the Wiki page and the previous threads on this
to see some of the earlier discussions. It's been suggested before
(although I realise you're asking for a comparison, rather than
necessarily making a suggestion). A brief summary below.
Joseph's point is a good start:
[...]
> STI is theoretically faster, but you can't really enforce db-level
> integrity constraints. The proposed implementation is theoretically
> slower (can involve a lot of joins for deep class hierarchies), but
> not null and foreign key contraints can actually be enforced at the db
> level. Those are the main points I remember, but there are many more.
The main constraint that is hard is NULL columns -- you can't have
not-NULL columns any more. Most other things can be faked (e.g. CHECK()
conditions and other constraint constructs) in many databases, but it's
a bit of effort.
Performance isn't as big an issue as people want to believe. Databases
are very fast. And, not surprisingly, they are very good at doing joins.
"Fast enough" is often a better goal then "as fast as possible", since
it's less fragile, easier to debug and maintain, and evolves with
changing technology more easily.
Other points against the single table model (in addition to NULL
constraints):
- doesn't integrate well with legacy databases
- doesn't work with third-party model inheritance
- multiple inheritance becomes really hard (you can't do it
perfectly with single tables for all cases). You may think this
isn't relevant, but mix-ins are surprisingly useful and some of
them will be database-backed.
- development, rollout and rollback are more painful and
error-prone (you need to keep altering tables instead of
creating and dropping separate ones)
- it's poor database table normalisation (lots of sparse
columns)
We will have a way to say that the base class (or classes) is
"abstract", meaning that its columns should be folded into the child
table. Then you can't query on the base class (maybe; it might even be
possible), but you get to share the common bits at the Python level.
That's an optimisation for people who know what they are doing and
understand the trade-offs. Most people probably won't need to care.
If you really need absolute "bits on the wire" database optimisation,
then there are many places in Django that will not be perfect for you --
although almost all of them can be worked around. The perceived
advantages of chasing the single table goal are far outweighed by the
advantages of using good database design. Sure that's a pretty
opinionated statement, but I feel I've worked with enough small and
largish databases (significant fractions of a terabyte) to have
developed some feel for where the trade-offs lie. Performance problems
never appear in the place you expect them. :-)
Hope that answers your question in part.
Best wishes,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" 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-developers
-~----------~----~----~----~------~----~------~--~---
