CODEWITHSUNDEEP
pythondjangodjango-modelsforeign-keysdata-modeling
jazzblue
jazzblue

Reputation: 2437

Django data modeling: Foreignkey or hard coded?

Suppose I have a table of animals which has two attributes name and type, whereas type can be: 'dog', 'cat', etc. Here are two ways to implement this in Django: one where type is a ForeignKey to AnimalType:

class Animal(models.Model):
    name = models.CharField(max_length=10)
    type = models.ForeignKey(AnimalType)

The other is to just have type as a predefined choice which would be defined in the imported module:

class Animal(models.Model):
    name = models.CharField(max_length=10)
    type = models.CharField(
        max_length=10,
        choices=ANIMAL_TYPE_CHOICES
    )

The latter (predefined choice) seems more efficient to me, since types will never be dynamically updated by user interaction and if a new type needs to be added it will be added by a developer, i.e. the code would be updated rather than the database.

However, I would like to know if this would be a good/acceptable practice? Or should I waste a separate database table for such a "static" entry and also pay with extra time caused by db accesses? Thanks.

Upvotes: 0

Views: 513

Answers (3)

Raydel Miranda
Raydel Miranda

Reputation: 14360

The first way has the advantage that you don't have to touch the code in order to add a new type of animal.

And of course, someone using your app neither.

Adding a new animal type is something trivial and, for instance, you shouldn´t be messing with a working code deployed on a production server for just add an animal type.

If you´re having problems due to your database is empty at start using the application and because of that you don't have any animal types, well, try Django fixtures: Providing initial data for models

Upvotes: 2

Renkai
Renkai

Reputation: 236

I prefer field choices due to performance reasons. Even if the potential choices increases, as long as the functionality is just a choice selection, there's no reason to create an extra table

Upvotes: 1

Denis Moskalets
Denis Moskalets

Reputation: 56

I prefer second way. If you don't need to edit types from admin panel and always will change it with changes in your code, you do not need to have ForeignKeys and separate table.

In case of ForeignKey, you will have additional integrity check on the database level. It can be useful if you delete some type and do not want to leave it in DB, for example.

Upvotes: 1

Related Questions