Code

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#17953 closed Cleanup/optimization (invalid)

DB architecture in tutorial

Reported by: hater.zlin@… Owned by: nobody
Component: Documentation Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Hi,

on page:

https://docs.djangoproject.com/en/1.3/intro/tutorial01/

you create DB architecture by this code:

from django.db import models

class Poll(models.Model):
    question = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')

class Choice(models.Model):
    poll = models.ForeignKey(Poll)
    choice = models.CharField(max_length=200)
    votes = models.IntegerField()

and I think in clean architecture it should be:

from django.db import models

class Poll(models.Model):
    question = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')

class Choice(models.Model):
    choice = models.CharField(max_length=200)
    votes = models.IntegerField()

class ChoiceToPollRelation(models.Model):
    poll = models.ForeignKey(Poll)
    choice = models.ForeignKey(Choice)

In this way, you are leading beginners to do errors from start.

Attachments (0)

Change History (2)

comment:1 Changed 2 years ago by carljm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

There's nothing wrong with a foreign key; it reflects that each choice can be related to one and exactly one poll (a one-to-many relationship). Your proposal is to change it to a many-to-many relationship, which is also fine if you need a single choice to be able to appear in multiple polls, but it's not better or cleaner (in fact it's worse if you want to enforce the one-to-many nature of the relationship).

If we were to use a many-to-many relationship here, the correct way to do that in Django would be to use a ManyToManyField, not a separate join model (given that there's no extra data about the relationship being stored).

But there's no reason to complicate the tutorial by using a ManyToManyField when a ForeignKey meets the need.

comment:2 Changed 2 years ago by hater.zlin@…

Thanks for quick reply.

Perhaps I've been too quick to open the ticket and my "statements" (you are leading beginners... and so) were offensive. Sorry. It should have been humble question. ;-)

I have to think about it more to make it clean to myself. Thak you once more.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.