Mon conseil sur la modélisation des données est :
- Vous devriez privilégier les colonnes facultatives (nullable) aux jointures 1:1 de manière générale . Il y a encore des cas où 1:1 a du sens, tournant généralement autour du sous-typage. Les gens ont tendance à être plus délicats lorsqu'il s'agit de colonnes nullables qu'ils ne le font bizarrement pour les jointures ;
- Ne faites pas un modèle trop indirect sauf si vraiment justifié (plus d'informations ci-dessous) ;
- La préférence se joint à l'agrégation. Cela peut varier, il doit donc être testé. Voir Oracle vs MySQL vs SQL Server :Agrégation vs jointures pour un exemple ;
- Les jointures sont meilleures que les sélections N+1. Une sélection N+1 consiste, par exemple, à sélectionner une commande dans une table de base de données, puis à émettre une requête distincte pour obtenir tous les articles de cette commande ;
- L'évolutivité des jointures est généralement seulement un problème lorsque vous effectuez des sélections de masse. Si vous sélectionnez une seule ligne et que vous la joignez ensuite à quelques éléments, cela pose rarement un problème (mais parfois c'est le cas) ;
- Les clés étrangères doivent toujours être indexé sauf si vous avez affaire à une table trivialement petite ;
Plus d'informations dans Erreurs de développement de base de données commises par les développeurs d'applications .
Maintenant, en ce qui concerne la franchise d'un modèle, permettez-moi de vous donner un exemple. Supposons que vous concevez un système d'authentification et d'autorisation des utilisateurs. Une solution sur-conçue pourrait ressembler à ceci :
- Alias (id, username, user_id) ;
- Utilisateur (identifiant, ... );
- E-mail (id, user_id, adresse e-mail) ;
- Connexion (id, user_id, ...)
- Rôles de connexion (id, login_id, role_id) ;
- Rôle (id, nom) ;
- Privilège de rôle (id, role_id, privilege_id) ;
- Privilège (id, nom).
Vous avez donc besoin de 6 jointures pour passer du nom d'utilisateur entré aux privilèges réels. Bien sûr, il pourrait y avoir une exigence réelle pour cela, mais le plus souvent, ce type de système est mis en place à cause de la torsion manuelle de certains développeurs pensant qu'ils pourraient un jour en avoir besoin, même si chaque utilisateur n'a qu'un seul alias, l'utilisateur à connecter est 1 :1 et ainsi de suite. Une solution plus simple est :
- Utilisateur (identifiant, nom d'utilisateur, adresse e-mail, type d'utilisateur)
et bien, c'est tout. Peut-être que si vous avez besoin d'un système de rôles complexe, mais il est également tout à fait possible que ce ne soit pas le cas et si vous le faites, il est raisonnablement facile de s'y intégrer (le type d'utilisateur devient une clé étrangère dans une table de types d'utilisateurs ou de rôles) ou il est généralement simple de mapper le ancien au nouveau.
C'est une question de complexité :c'est facile à ajouter et difficile à enlever. Habituellement, il s'agit d'une veille constante contre la complexité involontaire, ce qui est déjà assez grave sans aller et l'aggraver en ajoutant une complexité inutile.
