Comprendre les relations de modèle dans Laravel Eloquent

Maîtriser les Modèles et Relations dans Laravel Eloquent

Les modèles et leurs interconnexions sont au cœur du fonctionnement d'Eloquent, l'ORM de Laravel. Si vous éprouvez des difficultés à les comprendre, ou si vous cherchez un guide simple, accessible et exhaustif, vous êtes au bon endroit pour commencer votre apprentissage !

Il est aisé pour un auteur d'articles techniques d'exagérer son expertise, ou de faire croire que l'utilisation d'une plateforme est simple. Pour ma part, je vais être transparent : j'ai vraiment eu du mal à apprendre Laravel, notamment parce que c'était mon premier framework full-stack. L'une des raisons était que je ne l'utilisais pas dans le cadre professionnel, je l'explorais par curiosité. Je faisais une tentative, j'arrivais à un certain point, je ne comprenais plus, j'abandonnais et finissais par tout oublier. J'ai dû répéter ce processus 5 ou 6 fois avant que les choses ne commencent à avoir du sens (et la documentation n'a pas toujours été d'une grande aide).

Toutefois, ce qui demeurait nébuleux, c'était Eloquent. Ou plutôt, les liens entre les modèles, car Eloquent est bien trop vaste pour être maîtrisé de bout en bout. Les exemples de modèles avec des auteurs et des articles de blog sont presque une plaisanterie, car les projets réels sont bien plus complexes. La documentation officielle emploie malheureusement ces mêmes exemples (ou des exemples similaires). Et quand bien même je trouvais un article ou une ressource utile, l'explication était si confuse ou incomplète que je n'en tirais rien.

(Au passage, on m'a déjà reproché d'avoir critiqué la documentation officielle, donc si vous avez des réflexions similaires, voici ma réponse : allez consulter la documentation de Django, et après on en reparle.)

Finalement, peu à peu, tout s'est éclairci, j'ai compris le mécanisme. J'ai fini par pouvoir modéliser les projets correctement et utiliser les modèles avec aisance. Puis, un jour, j'ai découvert quelques astuces sur les Collections, qui ont rendu ce travail plus agréable. Dans cet article, je vais aborder tous les aspects, en commençant par les bases, pour ensuite couvrir tous les cas d'usage que vous rencontrerez dans des projets réels.

Pourquoi les relations de modèles Eloquent sont-elles si ardues ?

Je suis malheureusement tombé sur beaucoup trop de développeurs Laravel qui ne comprenaient pas les modèles correctement.

Mais pourquoi donc ?

Même aujourd'hui, alors qu'il y a une profusion de formations, d'articles et de vidéos sur Laravel, le niveau de compréhension global reste assez faible. Je pense que c'est un point important qui mérite une réflexion.

Si on me demandait mon avis, je dirais que les relations entre modèles Eloquent ne sont pas difficiles en soi. Du moins, si on se place d'un point de vue de la définition de « difficile ». Les migrations de schémas en direct sont difficiles ; développer un nouveau moteur de template est difficile ; contribuer au code source de Laravel est difficile. Comparé à cela, apprendre et utiliser un ORM... c'est tout de même plus simple ! 🤭🤭

Ce qui se passe en réalité, c'est que les développeurs PHP qui débutent avec Laravel trouvent Eloquent difficile. C'est le véritable problème de fond, et, à mon avis, il y a plusieurs facteurs qui contribuent à cela (attention, opinion non consensuelle !) :

Avant Laravel, la plupart des développeurs PHP avaient été confrontés à CodeIgniter (qui est d'ailleurs toujours actif, même s'il est devenu plus proche de Laravel/CakePHP). Dans l'ancienne communauté CodeIgniter (si tant est qu'il y en avait une), la « meilleure pratique » consistait à coller directement les requêtes SQL là où elles étaient nécessaires. Et bien qu'il existe un nouveau CodeIgniter aujourd'hui, les habitudes persistent. Par conséquent, quand ils apprennent Laravel, l'idée d'un ORM est une nouveauté absolue pour les développeurs PHP.
Hormis le très faible pourcentage de développeurs PHP ayant été exposés à des frameworks comme Yii, CakePHP, etc., le reste est habitué à travailler avec du PHP pur ou dans un environnement comme WordPress. Et là encore, une logique orientée objet n'existe pas, donc un framework, un conteneur de services, un modèle de conception, un ORM… ce sont des concepts complètement étrangers.
Dans le monde PHP, il n'y a pas ou peu de concept d'apprentissage continu. Le développeur moyen se contente de travailler avec des configurations sur un seul serveur en utilisant des bases de données relationnelles et en exécutant des requêtes écrites sous forme de chaînes de caractères. Programmation asynchrone, web sockets, HTTP 2/3, Linux (sans parler de Docker), tests unitaires, Domain-Driven Design – toutes ces idées sont étrangères à la majorité des développeurs PHP. Par conséquent, l'apprentissage de concepts nouveaux et stimulants, au point de les maîtriser, n'arrive pas lors de la rencontre avec Eloquent.
La compréhension globale des bases de données et de la modélisation est également faible. Étant donné que la conception de la base de données est directement et indissociablement liée aux modèles Eloquent, cela augmente encore la difficulté.

Je ne veux pas être dur ou généraliser à outrance – il existe aussi d'excellents développeurs PHP, et ils sont nombreux, mais leur pourcentage global est très faible.

Si vous lisez ceci, cela signifie que vous avez surmonté toutes ces barrières, que vous avez découvert Laravel et que vous avez joué avec Eloquent.

Félicitations ! 👏

Vous êtes presque arrivé. Tous les éléments de base sont en place, il ne nous reste qu'à les parcourir dans le bon ordre et en détail. Autrement dit, commençons par les fondations : la base de données.

Modèles de base de données : relations et cardinalité

Pour simplifier, considérons que nous travaillons uniquement avec des bases de données relationnelles dans cet article. La première raison est que les ORM ont initialement été développés pour les bases de données relationnelles. La deuxième raison est que les SGBDR sont toujours extrêmement répandus.

Modèle de données

Avant tout, essayons de mieux comprendre les modèles de données. L'idée d'un modèle (ou d'un modèle de données pour être plus précis), vient de la base de données. Pas de base de données, pas de données, donc pas de modèle de données. Et qu'est-ce qu'un modèle de données ? C'est tout simplement la manière dont vous choisissez de stocker/structurer vos données. Par exemple, dans une boutique en ligne, vous pouvez tout stocker dans une table géante (une pratique horrible, mais malheureusement courante dans le monde du PHP). Ce serait votre modèle de données. Vous pouvez aussi diviser vos données en 20 tables principales et 16 tables de liaison, c'est également un modèle de données.

Notez que la façon dont les données sont structurées dans la base de données ne doit pas forcément correspondre à 100 % à la façon dont elles sont organisées dans l'ORM du framework. Cependant, l'objectif est de toujours faire en sorte que les deux soient le plus proches possible afin d'éviter de devoir gérer un concept supplémentaire pendant le développement.

Cardinalité

Éclaircissons rapidement ce terme : la cardinalité. Elle fait simplement référence au « compte », en gros. Autrement dit, 1, 2, 3… sont tous des cardinalités possibles. Fin de l'histoire. Poursuivons !

Relations

Maintenant, chaque fois que nous stockons des données dans un système, il y a des moyens de relier les points de données entre eux. Je sais que cela semble abstrait et ennuyeux, mais suivez-moi un instant. Les manières dont les différents éléments de données sont liés sont appelées des relations. Commençons par quelques exemples ne reposant pas sur des bases de données afin d'être certains que nous comprenons parfaitement le concept.

Si nous stockons tout dans un tableau, une relation possible est : l'élément de données suivant se trouve à un index supérieur de 1 par rapport à l'index précédent.
Si nous stockons des données dans un arbre binaire, une relation possible est : l'arbre enfant de gauche contient toujours des valeurs plus petites que celles du nœud parent (si nous faisons le choix de structurer l'arbre de cette manière).
Si nous stockons les données sous forme d'un tableau de tableaux de longueur égale, nous pouvons imiter une matrice, et ses propriétés deviennent alors les relations pour nos données.

Nous voyons donc que le mot « relation », dans le contexte des données, n'a pas de signification figée. En fait, si deux personnes étudiaient les mêmes données, elles pourraient identifier deux relations de données très différentes (bonjour, les statistiques !) et les deux pourraient être valides.

Bases de données relationnelles

En nous appuyant sur tous les termes dont nous avons discuté jusqu'à présent, nous pouvons enfin aborder un sujet qui a un lien direct avec les modèles dans un framework web (Laravel) : les bases de données relationnelles. Pour la plupart d'entre nous, la base de données principale utilisée est MySQL, MariaDB, PostgreSQL, MSSQL, SQL Server, SQLite ou un système similaire. Nous savons peut-être aussi vaguement que ce sont des SGBDR, mais la plupart d'entre nous ont oublié ce que cela veut vraiment dire et pourquoi c'est important.

Le « R » dans SGBDR signifie relationnel, évidemment. Ce n'est pas un terme choisi au hasard ; par cela, nous soulignons le fait que ces systèmes de bases de données sont conçus pour gérer efficacement les relations entre les données stockées. En fait, le terme « relation » a ici une signification mathématique stricte, et bien qu'aucun développeur n'ait besoin de s'en soucier, il est utile de savoir qu'il existe une logique mathématique fondamentale sous-jacente à ces types de bases de données.

Explorez ces ressources pour en savoir plus sur SQL et NoSQL.

Très bien, nous savons donc par expérience que les données dans les SGBDR sont stockées sous forme de tables. Mais où sont les relations ?

Types de relations dans les SGBDR

C'est peut-être la partie la plus importante de tout ce qui concerne Laravel et les relations entre modèles. Si vous ne comprenez pas cela, Eloquent n'aura jamais de sens, alors soyez attentif pendant les prochaines minutes (ce n'est même pas si difficile).

Un SGBDR nous permet de créer des relations entre les données, au niveau de la base de données. Cela signifie que ces relations ne sont pas irréalisables, imaginaires ou subjectives, et qu'elles peuvent être créées ou déduites par différentes personnes avec le même résultat.

Par ailleurs, un SGBDR propose certaines capacités/outils qui nous permettent de créer et d'appliquer ces relations, comme :

Clé primaire
Clé étrangère
Contraintes

Je ne veux pas transformer cet article en cours sur les bases de données, donc je suppose que vous connaissez ces concepts. Si ce n'est pas le cas, ou si vous avez des doutes, je vous recommande cette vidéo accessible (n'hésitez pas à explorer toute la série) :

Il se trouve que ces relations de type SGBDR sont aussi les plus courantes dans les applications du monde réel (pas toujours, car un réseau social est mieux modélisé sous forme de graphe et non comme une collection de tables). Examinons-les donc une par une et essayons aussi de comprendre où elles pourraient être utiles.

Relation un à un

Dans la quasi-totalité des applications web, il existe des comptes utilisateurs. De plus, les éléments suivants sont vrais (de manière générale) concernant les utilisateurs et les comptes :

Un utilisateur ne peut avoir qu'un seul compte.
Un compte ne peut appartenir qu'à un seul utilisateur.

Bien sûr, on peut affirmer qu'une personne peut s'inscrire avec une autre adresse e-mail et ainsi créer deux comptes, mais du point de vue de l'application web, ce sont deux personnes distinctes avec deux comptes distincts. L'application ne va pas, par exemple, afficher les données d'un compte dans un autre.

Cela signifie que si vous avez une telle situation dans votre application et que vous utilisez une base de données relationnelle, vous devez la concevoir comme une relation un à un. Notez que personne ne vous force artificiellement, c'est une situation claire dans le domaine fonctionnel, et il se trouve que vous utilisez une base de données relationnelle... c'est seulement lorsque ces deux conditions sont réunies qu'une relation un à un est appropriée.

Pour cet exemple (utilisateurs et comptes), voici comment nous pouvons implémenter cette relation lors de la création du schéma :

CREATE TABLE users(
    id INT NOT NULL AUTO_INCREMENT,
    email VARCHAR(100) NOT NULL,
    password VARCHAR(100) NOT NULL,
    PRIMARY KEY(id)
);

CREATE TABLE accounts(
    id INT NOT NULL AUTO_INCREMENT,
    role VARCHAR(50) NOT NULL,
    PRIMARY KEY(id),
    FOREIGN KEY(id) REFERENCES users(id)
);

Vous remarquez l'astuce ? C'est assez rare lors de la création d'applications en général, mais dans la table des comptes, le champ id est défini à la fois comme clé primaire et comme clé étrangère ! La propriété de clé étrangère le relie à la table des utilisateurs (logique 🙄) tandis que la propriété de clé primaire fait que la colonne id est unique – une vraie relation un à un !

Bien sûr, la fidélité de cette relation n'est pas garantie. Par exemple, rien ne m'empêche d'ajouter 200 nouveaux utilisateurs sans ajouter une seule entrée dans la table des comptes. Si je fais cela, je me retrouve avec une relation un à zéro ! 🤭🤭 Mais, dans les limites de la structure pure, c'est le mieux que nous puissions faire. Si nous voulons empêcher l'ajout d'utilisateurs sans compte, nous devons utiliser une logique de programmation, sous forme de déclencheurs de base de données ou de validations appliquées par Laravel.

Si vous commencez à stresser, voici quelques conseils précieux :

Allez-y doucement. Aussi lentement que nécessaire. Au lieu d'essayer de terminer cet article et les 15 autres que vous avez mis en favoris pour aujourd'hui, concentrez-vous sur celui-ci. Accordez-lui 3, 4, 5 jours si c'est nécessaire – votre objectif doit être de faire disparaître définitivement les relations entre modèles Eloquent de votre liste de problèmes. Vous êtes déjà passé d'un article à l'autre auparavant, en perdant des centaines d'heures, et cela n'a pas fonctionné. Faites quelque chose de différent cette fois-ci. 😇
Bien que cet article porte sur Laravel Eloquent, tout cela vient bien plus tard. Le schéma de la base de données est le fondement de tout cela, nous devons donc nous concentrer d'abord sur la maîtrise de cet aspect. Si vous n'arrivez pas à travailler uniquement au niveau de la base de données (en supposant qu'il n'y ait pas de framework), alors les modèles et les relations n'auront jamais de sens. Alors, oubliez Laravel pour le moment. Complètement. Pour l'instant, nous ne faisons que de la conception de bases de données. Oui, je ferai des références à Laravel de temps en temps, mais votre travail consiste à les ignorer complètement si elles rendent les choses plus complexes pour vous.
Par la suite, approfondissez vos connaissances sur les bases de données et ce qu'elles offrent. Index, performances, déclencheurs, structures de données sous-jacentes et leur comportement, mise en cache, relations dans MongoDB… tous les sujets connexes que vous aborderez vous aideront en tant qu'ingénieur. N'oubliez pas que les modèles des frameworks ne sont que des façades ; la véritable puissance d'une plateforme provient de ses bases de données sous-jacentes.

Relation un-à-plusieurs

Je ne sais pas si vous l'avez remarqué, mais c'est le type de relation que nous créons tous intuitivement dans notre travail quotidien. Quand nous créons une table de commandes (un exemple hypothétique), par exemple, pour stocker une clé étrangère dans la table des utilisateurs, nous créons une relation un-à-plusieurs entre les utilisateurs et les commandes. Pourquoi ? Eh bien, regardez à nouveau du point de vue de qui peut en avoir combien : un utilisateur a le droit d'avoir plusieurs commandes, ce qui correspond au fonctionnement du commerce électronique. Et vu de l'autre côté, la relation indique qu'une commande ne peut appartenir qu'à un seul utilisateur, ce qui est également logique.

Dans les ouvrages sur la modélisation des données RDBMS et dans la documentation système, cette situation est représentée schématiquement comme suit :

Vous remarquez les trois traits formant une sorte de trident ? C'est le symbole de « plusieurs », et ce schéma indique donc qu'un utilisateur peut avoir plusieurs commandes.

Soit dit en passant, ces décomptes « plusieurs » et « un » que nous rencontrons souvent sont ce qu'on appelle la cardinalité d'une relation (vous vous souvenez de ce mot d'une section précédente ?). Encore une fois, pour cet article, le terme n'a aucune utilité, mais il est bon de connaître ce concept au cas où vous le rencontreriez lors d'entretiens ou d'autres lectures.

Simple, n'est-ce pas ? Et en termes de code SQL, la création de cette relation est également simple. En fait, c'est bien plus simple que dans le cas d'une relation un à un !

CREATE TABLE users( 
    id INT NOT NULL AUTO_INCREMENT, 
    email VARCHAR(100) NOT NULL, 
    password VARCHAR(100) NOT NULL, 
    PRIMARY KEY(id) 
);

CREATE TABLE orders( 
    id INT NOT NULL AUTO_INCREMENT, 
    user_id INT NOT NULL, 
    description VARCHAR(50) NOT NULL, 
    PRIMARY KEY(id), 
    FOREIGN KEY(user_id) REFERENCES users(id) 
);

La table des commandes stocke les identifiants d'utilisateur pour chaque commande. Comme il n'y a pas de contrainte (restriction) imposant que les identifiants d'utilisateur dans la table des commandes soient uniques, cela signifie que nous pouvons répéter plusieurs fois le même identifiant. C'est ce qui crée la relation un à plusieurs, et non pas une quelconque magie occulte. Les identifiants d'utilisateur sont stockés de façon basique dans la table des commandes, et SQL n'a pas de concept de un à plusieurs, un à un, etc. Mais une fois que nous stockons les données de cette façon, nous pouvons considérer qu'il y a une relation un à plusieurs.

J'espère que tout cela est clair maintenant. Ou, au moins, plus clair qu'avant. 😅 N'oubliez pas que, comme tout le reste, il ne s'agit que d'une question d'entraînement, et une fois que vous aurez pratiqué 4 ou 5 fois dans des situations réelles, vous n'y penserez même plus.

Relations plusieurs à plusieurs

Le type de relation suivant qui se présente souvent dans la pratique est la relation dite plusieurs à plusieurs. Encore une fois, avant de nous préoccuper des frameworks ou même de nous plonger dans les bases de données, réfléchissons à un exemple concret : les livres et les auteurs. Pensez à votre auteur préféré : il ou elle a écrit plus d'un livre, n'est-ce pas ? Parallèlement, il est assez fréquent de voir plusieurs auteurs collaborer sur un livre (en tout cas, dans le genre documentaire). Ainsi, un auteur peut écrire plusieurs livres, et plusieurs auteurs peuvent écrire un livre. Entre ces deux entités (livre et auteur), il y a une relation plusieurs à plusieurs.

Maintenant, comme il est peu probable que vous développiez une application réelle impliquant des bibliothèques ou des livres et des auteurs, réfléchissons à quelques exemples supplémentaires. Dans un contexte B2B, un fabricant commande des articles à un fournisseur, et reçoit une facture en retour. La facture comportera plusieurs articles, chacun indiquant la quantité et l'article fourni : par exemple, des morceaux de tuyau de 5 pouces x 200, etc. Dans ce cas, les articles et les factures ont une relation plusieurs à plusieurs (réfléchissez-y et vous en serez convaincu). Dans un système de gestion de flotte, les véhicules et les conducteurs auront une relation similaire. Dans un site de commerce électronique, les utilisateurs et les produits peuvent avoir une relation plusieurs à plusieurs si on prend en compte des fonctions telles que les favoris ou les listes de souhaits.

Très bien, mais comment créer cette relation plusieurs à plusieurs en SQL ? En nous basant sur notre compréhension du fonctionnement de la relation un à plusieurs, il pourrait être tentant de penser que nous devrions stocker les clés étrangères de l'autre table dans les deux tables. Cependant, nous rencontrons des problèmes majeurs si nous essayons de faire cela. Jetez un coup d'œil à cet exemple où les livres sont censés avoir une relation plusieurs à plusieurs avec les auteurs :

À première vue, tout semble correct : les livres sont mis en correspondance avec les auteurs de manière plusieurs à plusieurs. Mais regardez attentivement les données de la table des auteurs : les identifiants de livre 12 et 13 sont tous les deux écrits par Peter M. (identifiant d'auteur 2), c'est pourquoi nous n'avons pas d'autre choix que de répéter des entrées. Non seulement la table des auteurs a maintenant des problèmes d'intégrité des données (proprement dit, normalisation et tout ça), mais en plus, les valeurs de la colonne id se répètent. Cela signifie que, dans la conception que nous avons choisie, il ne peut y avoir de colonne de clé primaire (car les clés primaires ne peuvent pas avoir de doublons), et tout s'écroule.

Nous avons manifestement besoin d'une nouvelle façon de faire, et heureusement ce problème a déjà été résolu. Puisque le stockage des clés étrangères directement dans les deux tables complique les choses, la bonne méthode pour créer des relations plusieurs à plusieurs dans les SGBDR consiste à créer une table dite « de jointure ». L'idée est en substance de laisser intactes les deux tables d'origine, et de créer une troisième table pour indiquer le mappage plusieurs à plusieurs.

Reprenons l'exemple qui a échoué en incluant une table de jointure :

Notez qu'il y a eu des changements importants :

Le nombre de colonnes dans la table des auteurs est réduit.
Le nombre de colonnes dans la table des livres est réduit.
Le nombre de lignes dans la table des auteurs est réduit, car il n'est plus nécessaire de faire de répétition.
Une nouvelle table appelée author_books est apparue, contenant des informations sur quel identifiant d'auteur est lié à quel identifiant de livre. Nous aurions pu nommer la table de jointure comme nous le voulions, mais par convention, il s'agit simplement du résultat de la fusion des deux tables qu'elle représente, avec un trait de soulignement.

La table de jointure n'a pas de clé primaire, et dans la plupart des cas, elle ne contient que deux colonnes : les identifiants des deux tables. C'est presque comme si nous avions supprimé les colonnes de clé étrangère de notre exemple précédent et que nous les avions collées dans cette nouvelle table. Puisqu'il n'y a pas de clé primaire, il peut y avoir autant de répétitions que nécessaire pour enregistrer toutes les relations.

Maintenant, nous pouvons voir comment la table de jointure affiche clairement les relations, mais comment y accéder dans nos applications ? Le secret est dans le nom : table de jointure. Ce n'est pas un cours sur les requêtes SQL, donc je n'entrerai pas dans les détails, mais l'idée est que si vous voulez tous les livres d'un auteur spécifique dans une requête efficace, vous effectuez une jointure SQL sur les tables dans le même ordre : auteurs, auteurs_livres et livres. Les tables auteurs et auteurs_livres sont jointes sur les colonnes id et author_id, respectivement, tandis que les tables author_books et books sont jointes sur les colonnes book_id et id, respectivement.

C'est fastidieux, oui. Mais voyez le bon côté des choses, nous avons terminé toute la théorie et tout le travail de base que nous devions faire avant de nous attaquer aux modèles Eloquent. Et laissez-moi vous rappeler que tout cela n'est pas optionnel ! Si vous ne maîtrisez pas la conception de bases de données, vous serez toujours perdu avec Eloquent. Par ailleurs, tout ce qu'Eloquent fait ou tente de faire reflète parfaitement ces éléments au niveau de la base de données. Il est donc facile de comprendre pourquoi essayer d'apprendre Eloquent en ignorant les SGBDR est un exercice vain.

Création de relations de modèles dans Laravel Eloquent

Enfin, après un détour de plus de 100 000 kilomètres, nous sommes arrivés au point où nous pouvons parler d'Eloquent, de ses modèles et de la façon de les créer/utiliser. Nous avons appris dans la partie précédente de l'article que tout commence par la base de données et la façon dont vous modélisez vos données. J'en ai conclu qu'il me fallait utiliser un seul exemple complet où je démarre un nouveau projet. En même temps, je veux que cet exemple soit réaliste, et non pas des blogs et des auteurs ou des livres et des étagères (qui sont aussi réels, mais qui ont été surexploités).

Imaginons une boutique qui vend des peluches. Imaginons également que nous ayons reçu le document des spécifications, à partir duquel nous pouvons identifier ces quatre entités dans le système : utilisateurs, commandes, factures, articles, catégories, sous-catégories et transactions. Oui, il y aura probablement d'autres complications, mais laissons cela de côté et concentrons-nous sur la façon dont nous passons d'un document à une application.

Une fois que les principales entités du système ont été identifiées, nous devons réfléchir à la façon dont elles sont liées entre elles, en termes de relations de base de données dont nous avons parlé jusqu'à présent. Voici celles auxquelles je pense :

Utilisateurs et commandes : un à plusieurs.
Commandes et factures : un à un. Je suis conscient que cette relation n'est pas toujours claire, et selon votre domaine d'activité, elle peut être un à plusieurs, plusieurs à un ou plusieurs à plusieurs. Cependant, dans le cas d'une petite boutique en ligne, une commande n'entraînera qu'une seule facture et inversement.
Commandes et articles : plusieurs à plusieurs.
Articles et catégories : plusieurs à un. Encore une fois, ce n'est pas forcément le cas dans les grands sites de commerce électronique, mais nous travaillons sur une petite entité.
Catégories et sous-catégories : un à plusieurs. Là encore, vous trouverez la plupart des exemples réels qui contredisent cela, mais bon, Eloquent est déjà assez difficile comme ça, n'allons pas rendre la modélisation des données encore plus compliquée !
Commandes et transactions : un à plusieurs. J'aimerais également ajouter ces deux points pour justifier mon choix : 1) Nous aurions aussi pu ajouter une relation entre les transactions et les factures. C'est simplement un choix de modélisation des données. 2) Pourquoi un à plusieurs ici ? Eh bien, il est courant qu'un paiement d'une commande échoue pour une raison quelconque, et fonctionne correctement la fois suivante. Dans ce cas, nous avons deux transactions créées pour cette commande. Le fait de vouloir afficher ou non ces transactions échouées est une décision commerciale, mais c'est toujours une bonne idée de collecter les données précieuses.

Existe-t-il d'autres relations ? Bien sûr, il y a beaucoup d'autres relations possibles, mais elles ne sont pas pratiques. Par exemple, nous pouvons dire qu'un utilisateur a de nombreuses transactions, et qu'il devrait donc y avoir une relation entre elles. Ce qu'il faut comprendre ici, c'est qu'il existe déjà une relation indirecte : utilisateurs -> commandes -> transactions, et de manière générale, c'est une bonne chose car les SGBDR sont des experts en jointure de tables. Deuxièmement, la création de cette relation entraînerait l'ajout d'une colonne user_id à la table des transactions. Si nous faisions cela pour chaque relation directe possible, nous ajouterions beaucoup de charge à la base de données (sous forme d'espace de stockage, surtout si des UUID sont utilisés, et de la maintenance des index), ce qui ralentirait l'ensemble du système. Bien sûr, si l'entreprise nous dit qu'elle a besoin de données sur les transactions dans un délai de 1,5 seconde, nous pourrions décider d'ajouter cette relation et d'accélérer le processus (compromis, compromis...).

Et maintenant, mesdames et messieurs, l'heure est venue d'écrire du vrai code !