Malcolm Tredinnick wrote: > On Sun, 2006-07-23 at 17:12 +0100, Bill de hÓra wrote: > > Malcolm Tredinnick wrote: > > > ----------------------- > > > 3. What you don't get > > > ----------------------- > > > [...] > > > I am not implementing the "everything in one table" storage model. It is > > > not universally applicable (you can't inherit from third-party models, > > > for a start) and I have software engineering objections to it. > > > > Why? NOT NULL constraints in the children? > > That's one good reason. It's also not very normalised; table design with > lots of sparse columns won't get me invited to the cool parties. Wide > rows where you only need to access a few fields tend to not always > perform as well as people might like (I'm talking about very large > datasets here; small datasets don't matter so much). > > Finally, because I would like to support extending third-party models > out of the box, we need the multi-table model and I don't want/need the > extra complexity of more and more alternatives right now. That's > something somebody could add later if their continued existence depended > on it. It's all "under the covers" work. > > I'm on a "pick one thing, do it well" drive at the moment (with a slight > concession to the abstract base class case).
The big downside to one table to hold all data would be that if I ever added a new derived class, I need to rebuild the table for _all_ other classes. Unless you pair this with schema evolution, that would seem to be a showstopper. -Dave --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
