Oh sorry, thought you wanted multiple categories per photo. Tim's response above is good.
As he said, I'd go with the ForeignKey approach, this makes the categories easier to manage and gives you further flexibility of storing additional information within each category (if you want). Also his examples of choices are good, it will be a bit of a pain if you use choices and choose to rename or remove any of them. On Sep 9, 1:36 pm, Léon Dignòn <[email protected]> wrote: > Hello Peter, > > sorry, I was talking about choices, not a choice > field:http://docs.djangoproject.com/en/dev/ref/models/fields/#choices > > Since any photo can only belong to one category (because I say so :) I > would tend towards using 1:N instead of M:N. Or did I missunderstand > you? If one photo can belong to several cetegories, I would use your > ManyToManyField, is that right? > > You say that an object should be represented as a table in SQL. I know > that, too. But the choices I mentioned above, are confusing me. Can > you explain me why they exist, or give me a good example that justify > choices? > > -leond > > On Sep 9, 6:36 pm, Peter Coles <[email protected]> wrote: > > > Hey Léon, > > > ChoiceField is a form field, not a table column—maybe you're thinking > > about CommaSeparatedIntegerField? You could use that and hardcode > > which categories represent which ids in your python > > code.http://docs.djangoproject.com/en/dev/ref/models/fields/#commaseparate... > > > On the other hand, the standard way of representing an object and its > > categories in SQL is to use a ManyToMany relation. This approach > > easily handles everything you want to do in a much easier to manage > > format, and it's unlikely that you'll need to worry about "bloat"— > > optimizing how you serve web pages, static files, caching, etc. will > > give you *many* more gains than holding off from adding another table > > to your db. > > > To setup your category, you can add something like this to your models > > file (above your photos model): > > > class Category(models.Model): > > title = models.CharField(max_length=100) > > slug = models.SlugField(unique=True) > > class Admin: > > pass > > > and then inside your photos model add a new column: > > > categories = models.ManyToManyField(Category, blank=True) > > > -Peter > > > On Sep 9, 11:54 am, Léon Dignòn <[email protected]> wrote: > > > > Hello, > > > > let's assume we have a model for photos with the fields id, user, > > > photo. Any user should be able to categorize his foto with a given > > > number of categories, e.g. person, car, building. In future it's > > > possible that I add more categories. > > > > My question is whether the new category field should be a ChoiceField, > > > or a ForeignKey? > > > > I would prefer a ChoiceField because > > > - I am 99% sure that there won't be new categories. > > > - the only person who maybe adds a new category will be me. > > > - another model would bloat up my database and my models.py > > > > But maybe I should use a ForeignKey because, > > > - I don't have to edit the model/table. > > > - it's easier to add a choice to a table than in the source code. > > > - because values in databases should be atomic. > > > > Otherwise, assuming that syncdb can't handle adding new choices to an > > > existing table, adding a choice directly in the database application > > > (MySQL, PostgreSQL) is no problem. Removing a choice won't happen.- Hide > > > quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
