[Igor Korot]

Hi, ALL,
This is my first official post here so be gentle... ;-)

I'm trying to make an application based on the following db structure:

table 1: id - primary key, fname char(40), lname char(40)
table 2: id - primary key, position char(20)
table 3: table1_id, table2_id - foreign key

Now, from what I understand Django does not work well with tables
without PK. So in order to make it around it just makes a bogus
primary key in the table called id.

What I'd like to know is this: there is no point of creating a PK for
a table 3. In fact it is wrong as it completely destroys the purpose
of the db schema.
Can I prevent the creation of the PK in this one table somehow? If its
not possible, is there a place where I can submit this as a
bug/feature request?

Thank you for any help.

[James Schneider]

It looks like you are trying to emulate a many-to-many relationship between two models. Tables 1 and 2 would be generated by model definitions, and table 3 would be created automagically by linking the two models together via a M2M field (which would NOT add an 'id' field as you've requested IIRC). Check out the documentation on the Django ORM, this section specifically:

https://docs.djangoproject.com/en/1.6/topics/db/models/#many-to-many-relationships

This would only apply if you intend to use Django's ORM (which I recommend in this simple example, and in almost every other example ever).

Alternatively, there is nothing stopping you from using whatever schema you like, as you can generate queries on your own, although I think the ORM would provide a large benefit both in code efficiency and security.

I have yet to find an instance where the ORM is not simpler to use than a custom query, although advanced schema's with pre-existing data or extreme query optimization may call for it. In general, though, if the ORM doesn't seem to fit, usually it is due to a design that hasn't been thought out enough.

The Django developers have seen a database or two in their time. Have a bit of faith in their well-proven ORM abstraction layer, you'll be pleasantly surprised.

-James

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2BFnnTyii-umGTL%3D81PWWQP07ubyheZfTzmT5p%2Bzide-T0FvhA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Dewhirst]

On 3/05/2014 4:41 PM, Igor Korot wrote:
> Hi, ALL,
> This is my first official post here so be gentle... ;-)

Ok. Its usually worthwhile putting a subject in so people can decide
whether to look at your email. The old hands wouldn't bother with a
blank subject email and they are probably the ones who are best able to
help.

>
> I'm trying to make an application based on the following db structure:
>
> table 1: id - primary key, fname char(40), lname char(40)
> table 2: id - primary key, position char(20)
> table 3: table1_id, table2_id - foreign key
>
> Now, from what I understand Django does not work well with tables
> without PK. So in order to make it around it just makes a bogus
> primary key in the table called id.

Not so. Relational databases have engines which rely on each row in
every table having a PK so they can be safely stored and reliably
retrieved. They can use character columns as a PK but the engines are
optimised for integer PKs.

There is nothing bogus about it. That is the way the engines work.

Best practice in relational databases is to never know or more
correctly, never need to know what the PK value is. That is for the
engine not the human.

What Django is doing with PKs is respecting your right to do things in
your way because you might know better than standard best practice. In
other words, while every table needs a PK, Django puts it in for you if
you don't specify one. That's a good thing. Get into the habit of not
thinking about PKs.

>
> What I'd like to know is this: there is no point of creating a PK for
> a table 3. In fact it is wrong as it completely destroys the purpose
> of the db schema.

No. You can and should ignore the primary key. When you want to follow a
relationship in your program code, you just use/specify real-world
attributes of the objects concerned and let Django (or more correctly
the underlying database engine) find what you want.

> Can I prevent the creation of the PK in this one table somehow? If its
> not possible, is there a place where I can submit this as a
> bug/feature request?
>

You have probably already seen this
https://docs.djangoproject.com/en/1.7/ but it is well worth bookmarking.

I have never seen better documentation for a web framework in any
language. The people who wrote it need a Nobel prize or at least a daily
standing ovation.

In particular look at
https://docs.djangoproject.com/en/1.7/intro/tutorial01/#creating-models
and see that the two tables shown (Question and Choice) are related in a
similar way to your table 1 and table 2. No sign of any PK and no need
for table 3; yet Choice is related to Question in the sense a Question
can have many Choices. That is all there is to it.

If you wanted your table 2 to have a one-to-one relationship you would
use OneToOneField instead of ForeignKey. Simple. And still no table 3.
Look at
https://docs.djangoproject.com/en/1.7/ref/models/fields/#onetoonefield

On the other hand, if many Questions could have many of the same Choices
you would use ManyToManyField instead of ForeignKey. For this
circumstance, Django would (behind the scenes) cause the database engine
to create a third table called question_choice to store those
relationships. Look at
https://docs.djangoproject.com/en/1.7/ref/models/fields/#manytomanyfield

In all these cases, all you ever need to worry about is real-world
attributes of your objects and Django stores and retrieves them
correctly for you. The PK is always there but not your concern.

Good luck.