Si vous utilisez un champ tableau
- La taille de chaque ligne de votre base de données va être un peu grande donc Postgres va utiliser beaucoup plus de tables toast (http://www.postgresql.org/docs/9.5/static/storage-toast.html )
- Chaque fois que vous obtenez la ligne, sauf si vous utilisez spécifiquement
defer(https://docs.djangoproject.com/en/1.9 /ref/models/querysets/#defer ) le champ ou sinon l'exclure de la requête viaonly, ouvaluesou quelque chose, vous payez le coût du chargement de toutes ces valeurs chaque fois que vous parcourez cette ligne. Si c'est ce dont vous avez besoin, qu'il en soit ainsi. - Le filtrage basé sur les valeurs de ce tableau, bien que possible, ne sera pas aussi agréable et l'ORM de Django ne le rend pas aussi évident que pour les tables M2M.
Si vous utilisez le M2M
- Vous pouvez filtrer plus facilement ces valeurs associées
- Ces champs sont différés par défaut, vous pouvez utiliser
prefetch_relatedsi vous en avez besoin, puis devenez fantaisiste si vous ne voulez charger qu'un sous-ensemble de ces valeurs - Le stockage total dans la base de données va être légèrement plus élevé avec M2M en raison des clés et des champs d'identification supplémentaires
- Le coût des jointures dans ce cas est complètement négligeable à cause des clés.
Personnellement, je dirais aller avec les tables M2M, mais je ne connais pas votre application spécifique. Si vous allez travailler avec une quantité massive de données, il vaut probablement la peine de saisir un ensemble de données représentatif et de tester les deux méthodes avec.
