Nej, det gör relationen "ett till noll eller ett". Är det vad du verkligen behöver?
Om ja , då är din "andra lösning" bättre:
- det är enklare,
- tar mindre lagring (och gör därför cachen "större")
- det är färre index att underhålla, vilket gynnar datamanipulation,
- och (eftersom du använder InnoDB) naturligtvis kluster data, så användare som är nära varandra kommer också att ha sina konton lagrade nära varandra, vilket kan gynna cache-lokalisering och vissa typer av räckviddssökningar.
BTW, du måste skapa accounts.id ett vanligt heltal (inte automatisk ökning) för att detta ska fungera.
Om nej , se nedan...
Tja, "bäst" är ett överbelastat ord, men "standard"-lösningen skulle vara densamma som i vilken annan databas som helst:placera båda enheterna (användare och konto i ditt fall) i samma fysiska tabell.
Teoretiskt kan du göra cirkulära FK:er mellan de två PK:erna, men det skulle kräva uppskjuten begränsningar för att lösa problemet med kyckling och ägg, som tyvärr inte stöds under MySQL.
Jag har inte så mycket praktisk erfarenhet av just det modelleringsverktyget, men jag gissar att det beror på att det är "en till många" där "många" gränsades till 1 genom att göra det unikt. Kom ihåg att "många" inte betyder "1 eller många", det betyder "0 eller många", så den "begränsade" versionen betyder egentligen "0 eller 1".
Inte bara i lagringskostnaden för det extra fältet, utan också för det sekundära indexet. Och eftersom du använder InnoDB som alltid kluster tabeller , se upp att sekundära index är ännu dyrare i klustrade tabeller än de är i heapbaserade tabeller.
InnoDB kräver index på främmande nycklar.