On Mon, 2009-03-09 at 20:45 -0700, K*K wrote:
> Let me show you some data in database, you will understand it.
No, because that wasn't the question I was asking. I wasn't having
problems understanding the models. I was asking why you have to do one
query per Plan instance, instead of all together. See below for the
combined query and then explain why it isn't that easy.
[...]
>
> The most important thing is there are a lot of plans with the same
> plan_id but different plan_text_version in table plan_texts.
>
> But I have no idea how to model the two tables with relationshi, and
> there's no relationship field can connect between them.
You'll need to add a primary key column on the PlanText table, since
Django wants a pk that is a single column on every table. That can just
be an auto-increment sequence and you'll never need to use it explcitly
if you don't want to. That's why I said that having multi-column primary
keys doesn't change anything here: you can *always* model things
equivalently with single-column surrogate primary key.
As to the SQL query, if you give me a bunch of plan_id values, I can
retrieve all the relevant PlanText entries in a single query:
PlanText.objects.filter(plan__in=plan_id_values)
One query for any number of plan_id values. That's not a problem. You
can order that and everything.
The question I asked was: what triggers this retrieval process? Why are
you currently doing one retrieval for each individual plan_id instead of
pulling them all together like this? That isn't answered by showing me
the data.
The answer to your 2000 query issue is always going to be to restructure
things like this so that you collect the necessary plan_ids together and
pull them all at once. If you need help organising that, provide some
details on where the difficulty lies. Otherwise, you just need to add a
surrogate pk column to the plantext table and you're set. If you're
about to respond that the "designer" won't let you add any new column,
then switch to raw SQL or SQLAlchemy or whatever you like, because you
already know the answer to the multi-column primary key question and
adding a surrogate key isn't really any significant change to a database
schema, so if your designer wants to make needless restrictions like
that, you're simply going to have to compromise.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
