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.
Thank you for any help.
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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/5364A13F.3080304%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.
