Nee, dat maakt de relatie "één tot nul of één". Is dat wat je echt nodig hebt?
Indien ja , dan is uw "tweede oplossing" beter:
- het is eenvoudiger,
- neemt minder opslagruimte in beslag (en maakt de cache daarom "groter")
- hij hoeft minder indexen te onderhouden, wat de gegevensmanipulatie ten goede komt,
- en (aangezien je InnoDB gebruikt) natuurlijk clusters de gegevens, zodat gebruikers die dicht bij elkaar staan, hun accounts ook dicht bij elkaar hebben, wat de cachelocatie en bepaalde soorten bereikscans ten goede kan komen.
Trouwens, je moet accounts.id . maken een gewoon geheel getal (niet automatisch ophogen) om dit te laten werken.
Indien nee , zie hieronder...
Welnu, "beste" is een overbelast woord, maar de "standaard" oplossing zou hetzelfde zijn als in elke andere database:plaats beide entiteiten (gebruiker en account in uw geval) in dezelfde fysieke tabel.
Theoretisch zou je cirkelvormige FK's tussen de twee PK's kunnen maken, maar daarvoor zou uitgesteld nodig zijn. beperkingen om het kip-en-ei-probleem op te lossen, die helaas niet worden ondersteund onder MySQL.
Ik heb niet veel praktische ervaring met die specifieke modelleringstool, maar ik vermoed dat dat komt omdat het "één op veel" is waar "veel" kant op 1 werd beperkt door het uniek te maken. Onthoud dat "veel" niet "1 of veel" betekent, het betekent "0 of veel", dus de "afgetopte" versie betekent echt "0 of 1".
Niet alleen in de opslagkosten voor het extra veld, maar ook voor de secundaire index. En aangezien u InnoDB gebruikt die altijd tabellen clustert , pas op dat secundaire indexen zelfs duurder zijn in geclusterde tabellen dan in op heap gebaseerde tabellen.
InnoDB vereist indexen op buitenlandse sleutels.