Non, cela fait la relation "un à zéro ou un". Est-ce vraiment ce dont vous avez besoin ?
Si oui , alors votre "deuxième solution" est meilleure :
- c'est plus simple,
- occupe moins de stockage (et rend donc le cache "plus grand")
- il y a moins d'index à maintenir, ce qui profite à la manipulation des données,
- et (puisque vous utilisez InnoDB) naturellement grappes les données, de sorte que les utilisateurs proches verront également leurs comptes stockés à proximité, ce qui peut bénéficier à la localité du cache et à certains types d'analyses de plage.
BTW, vous devrez créer accounts.id un entier ordinaire (pas d'incrémentation automatique) pour que cela fonctionne.
Si non , voir ci-dessous...
Eh bien, "meilleur" est un mot surchargé, mais la solution "standard" serait la même que dans n'importe quelle autre base de données :mettre les deux entités (utilisateur et compte dans votre cas) dans la même table physique.
Théoriquement, vous pourriez faire des FK circulaires entre les deux PK, mais cela nécessiterait un report contraintes pour résoudre le problème de la poule et de l'œuf, qui ne sont malheureusement pas prises en charge sous MySQL.
Je n'ai pas beaucoup d'expérience pratique avec cet outil de modélisation particulier, mais je suppose que c'est parce que c'est "un à plusieurs" où le côté "plusieurs" a été plafonné à 1 en le rendant unique. N'oubliez pas que "plusieurs" ne signifie pas "1 ou plusieurs", cela signifie "0 ou plusieurs", donc la version "limitée" signifie vraiment "0 ou 1".
Pas seulement dans les dépenses de stockage pour le champ supplémentaire, mais aussi pour l'index secondaire. Et puisque vous utilisez InnoDB qui regroupe toujours les tables , sachez que les index secondaires sont encore plus chers dans les tables groupées que dans les tables basées sur le tas.
InnoDB nécessite des index sur les clés étrangères.
