9👍
You should also consider foreign keys when the number of potential choices is large. That’s one of the reasons to consider using FK for countries or states. Otherwise, you’re effectively hard-coding a lot of data in your source code.
20👍
I would use choices where the choices wouldn’t change over time. If they would, a FK with a new model would be better.
- [Django]-How to submit form without refreshing page using Django, Ajax, jQuery?
- [Django]-Django : get_or_create Raises duplicate entry with together_unique
- [Django]-Django REST Framework: how to substitute null with empty string?
3👍
I would recommend using lookup tables by default, otherwise you are maintaining data in your code. It also makes the lookup values accessible to users that access the database directly, not via your application (e.g. BI/reporting functions).
A notable exception – where I would use choices instead of a lookup table – is a lookup entity that has values that control code-level logic. You often find this with “status” or “type” entities (e.g. BillingType), where the logic depends on the value of the “type” field. In these cases, the code usually refers to explicit identifiers (codes) of those types, and the addition of a new type would require logic changes (in code) in any case.
- [Django]-Django template filter remove html tags
- [Django]-How can I make a trailing slash optional on a Django Rest Framework SimpleRouter
- [Django]-How to show a PDF file in a Django view?