Nej, det gør forholdet "en til nul eller en". Er det det, du rent faktisk har brug for?
Hvis ja , så er din "anden løsning" bedre:
- det er nemmere,
- tager mindre lagerplads (og gør derfor cachen "større")
- det er færre indekser at vedligeholde, hvilket gavner datamanipulation,
- og (da du bruger InnoDB) naturligvis klynger dataene, så brugere, der er tæt på hinanden, vil også have deres konti gemt tæt sammen, hvilket kan gavne cache-lokaliteten og visse former for rækkeviddescanninger.
BTW, du skal lave accounts.id et almindeligt heltal (ikke automatisk stigning) for at dette virker.
Hvis nej , se nedenfor...
Nå, "bedst" er et overbelastet ord, men "standard"-løsningen ville være den samme som i enhver anden database:sæt begge entiteter (bruger og konto i dit tilfælde) i den samme fysiske tabel.
Teoretisk set kunne du lave cirkulære FK'er mellem de to PK'er, men det ville kræve udskudt begrænsninger for at løse kylling-og-æg-problemet, som desværre ikke understøttes under MySQL.
Jeg har ikke meget praktisk erfaring med det specifikke modelleringsværktøj, men jeg gætter på, at det er fordi det er "en til mange", hvor "mange" side blev begrænset til 1 ved at gøre det unikt. Husk venligst, at "mange" ikke betyder "1 eller mange", det betyder "0 eller mange", så den "begrænsede" version betyder virkelig "0 eller 1".
Ikke kun i lagerudgiften for det ekstra felt, men også for det sekundære indeks. Og da du bruger InnoDB, som altid klynger tabeller , pas på, at sekundære indekser er endnu dyrere i klyngede tabeller, end de er i heap-baserede tabeller.
InnoDB kræver indekser på fremmednøgler.