Comment modélisez-vous les relations dans l'ORM ?

Question

Accepted Answer

L'ORM de Django modélise les trois relations de base fondamentales avec des types de champs dédiés : **ForeignKey** (un-à-plusieurs), **ManyToManyField** (plusieurs-à-plusieurs), et **OneToOneField** (un-à-un). Ces champs définissent comment les tables sont liées et vous donnent un accès Pythonic aux objets associés.

## ForeignKey — un-à-plusieurs (le plus courant)

```python
class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(
        Author,
        on_delete=models.CASCADE,        # what happens if the author is deleted
        related_name="books",            # access the reverse: author.books
    )
```

```python
# access related objects naturally:
book.author                # the Author this book belongs to (forward)
author.books.all()         # all Books by this author (reverse, via related_name)
```

Une `ForeignKey` modélise « plusieurs livres appartiennent à un auteur ». Le comportement `on_delete` (`CASCADE`, `PROTECT`, `SET_NULL`, etc.) est **requis** et définit ce qui se passe aux livres si l'auteur est supprimé.

## ManyToManyField — plusieurs-à-plusieurs

```python
class Article(models.Model):
    title = models.CharField(max_length=200)
    tags = models.ManyToManyField("Tag", related_name="articles")   # many tags ↔ many articles

class Tag(models.Model):
    name = models.CharField(max_length=50)
```

```python
article.tags.add(tag1, tag2)        # associate tags
article.tags.all()                   # all tags on this article
tag.articles.all()                   # all articles with this tag (reverse)
```

Django crée automatiquement la **table de jointure** derrière une `ManyToManyField` — vous utilisez simplement `.add()`, `.remove()`, `.all()`. (Pour des données supplémentaires sur la relation, utilisez un modèle `through`.)

## OneToOneField — un-à-un

```python
class User(models.Model):
    username = models.CharField(max_length=50)

class Profile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)   # one profile per user
    bio = models.TextField()
```

Une `OneToOneField` impose un lien strict un-à-un — couramment utilisée pour étendre un modèle (par ex. un Profile étendant un User).

## Options on_delete (important de bien choisir)

```text
CASCADE   → delete related objects too (delete author → delete their books)
PROTECT   → prevent deletion if related objects exist (raises an error)
SET_NULL  → set the FK to NULL (requires null=True) — keep the books, orphan them
SET_DEFAULT / SET(...) → set to a default/computed value
RESTRICT  → similar to PROTECT, with nuances
```

## Requêtes sur les relations

```python
# traverse relationships in queries with __ (double underscore)
Book.objects.filter(author__name="Tolkien")        # books whose author's name is Tolkien
Article.objects.filter(tags__name="python")         # articles tagged 'python'
```

## Pourquoi c'est important

Modéliser les relations correctement est fondamental pour travailler avec des données relationnelles dans Django — presque chaque application réelle a des entités associées (utilisateurs et articles, commandes et éléments, articles et balises), donc comprendre les trois types de champs de relation est une connaissance essentielle au quotidien.

Savoir quand utiliser chacun — **ForeignKey** pour un-à-plusieurs (le plus courant, comme les livres appartenant à un auteur), **ManyToManyField** pour plusieurs-à-plusieurs (comme les articles et les balises, avec Django gérant automatiquement la table de jointure), et **OneToOneField** pour un-à-un (comme étendre un utilisateur avec un profil) — est nécessaire pour concevoir tout modèle de données non trivial.

L'ORM rend les données associées **Pythonic et pratiques** (accédant à `book.author` et `author.books.all()` naturellement, interrogeant les relations avec `__`), mais deux aspects nécessitent de l'attention : choisir le **comportement `on_delete` correct** (une décision requise et conséquente — `CASCADE` supprime les objets associés, `PROTECT` empêche la suppression, `SET_NULL` les abandonne — mal le faire peut causer une perte de données accidentelle ou des erreurs d'intégrité), et utiliser `related_name` pour un accès inverse clair.

Comprendre la modélisation des relations, les options on_delete, et les requêtes cross-relation est essentiel pour construire des modèles de données Django corrects et bien conçus, et cela se connecte directement à l'optimisation des requêtes (puisque traverser les relations naïvement cause des problèmes N+1), ce qui en fait une connaissance fondamentale et fréquemment testée.