No, questo rende la relazione "uno a zero o uno". È quello che ti serve davvero?
Se sì , allora la tua "seconda soluzione" è migliore:
- è più semplice
- occupa meno spazio di archiviazione (e quindi rende la cache "più grande")
- ha meno indici da mantenere, il che avvantaggia la manipolazione dei dati,
- e (dato che stai usando InnoDB) naturalmente cluster i dati, così gli utenti che sono vicini avranno anche i loro account archiviati vicini, il che potrebbe avvantaggiare la località della cache e alcuni tipi di scansioni dell'intervallo.
A proposito, dovrai creare accounts.id un numero intero ordinario (non auto-incremento) affinché funzioni.
Se no , vedi sotto...
Bene, "migliore" è una parola sovraccarica, ma la soluzione "standard" sarebbe la stessa di qualsiasi altro database:metti entrambe le entità (utente e account nel tuo caso) nella stessa tabella fisica.
In teoria, potresti creare FK circolari tra i due PK, ma ciò richiederebbe un differimento vincoli per risolvere il problema dell'uovo e della gallina, che sfortunatamente non sono supportati da MySQL.
Non ho molta esperienza pratica con quel particolare strumento di modellazione, ma suppongo che sia perché è "uno a molti" in cui il lato "molti" è stato limitato a 1 rendendolo unico. Ricorda che "molti" non significa "1 o molti", significa "0 o molti", quindi la versione "limitata" significa in realtà "0 o 1".
Non solo nella spesa di archiviazione per il campo aggiuntivo, ma anche per l'indice secondario. E poiché stai usando InnoDB che raggruppa sempre le tabelle , fai attenzione che gli indici secondari sono ancora più costosi nelle tabelle in cluster che nelle tabelle basate sull'heap.
InnoDB richiede indici su chiavi esterne.
