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 <pe...@hunch.com> 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 <leon.dig...@gmail.com> 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 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 -~----------~----~----~----~------~----~------~--~---
