1π
-
Not having an actual constraint might lead to broken references, invalid parents and other sorts of data inconsistencies. I am not a Django expert but I would venture a guess that in most cases Django will still handle the relations fine unless you purposefully add some invalid records.
-
Normally, if your RDBMS supports foreign key constraints, there is absolutely no reason not to use them, and it could potentially be considered a design flaw to ignore them.
-
You should consider adding the key constraints. Not only do they give your DBMS a good idea of how to optimize the queries, they also ensure consistency in your data. I am pretty sure Django has a setting somewhere that will automatically generate the SQL to add the key constraints when you run
manage.py syncdb
For more information about why you should prefer foreign keys, you should read the MySQL Foreign Key Documentation
Most interestingly:
InnoDB requires indexes on foreign keys and referenced keys so that foreign key checks can be fast and not require a table scan. In the referencing table, there must be an index where the foreign key columns are listed as the first columns in the same order. Such an index is created on the referencing table automatically if it does not exist. (This is in contrast to some older versions, in which indexes had to be created explicitly or the creation of foreign key constraints would fail.) index_name, if given, is used as described previously.
0π
Its supposed to be faster β¦ since you mysql doesnβt check the constraint before adding a row in the child table.
But with the foreign key, it would make your life easier since you can use the on update and on delete.
Iβd go with the constraint.
- [Django]-Django custom User model authentication
- [Django]-Django multi-tenant
- [Django]-Django modelfield, how do I get the actual value?
- [Django]-Django-haystack elasticsearch as backend and searchengine
- [Django]-Multiple User Profiles in django-userena