Não, isso torna a relação "um para zero ou um". É isso que você realmente precisa?

Se sim , então sua "segunda solução" é melhor:

• é mais simples,
• consome menos armazenamento (e, portanto, torna o cache "maior")
• há menos índices para manter, o que beneficia a manipulação de dados,
• e (já que você está usando o InnoDB) naturalmente agrupamentos os dados, para que os usuários próximos também tenham suas contas armazenadas próximas, o que pode beneficiar a localidade do cache e certos tipos de varreduras de intervalo.

BTW, você precisará criar accounts.id um inteiro comum (não auto-incremento) para que isso funcione.

Se não , ver abaixo...

Bem, "melhor" é uma palavra sobrecarregada, mas a solução "padrão" seria a mesma de qualquer outro banco de dados:coloque as duas entidades (usuário e conta no seu caso) na mesma tabela física.

Teoricamente, você poderia fazer FKs circulares entre os dois PKs, mas isso exigiria diferido restrições para resolver o problema do ovo e da galinha, que infelizmente não são suportados no MySQL.

Não tenho muita experiência prática com essa ferramenta de modelagem específica, mas acho que é porque é "um para muitos", onde o lado "muitos" foi limitado a 1, tornando-o único. Por favor, lembre-se que "muitos" não significa "1 ou muitos", significa "0 ou muitos", então a versão "limitada" realmente significa "0 ou 1".

Não apenas na despesa de armazenamento para o campo adicional, mas também para o índice secundário. E como você está usando o InnoDB que sempre agrupa tabelas , esteja ciente de que os índices secundários são ainda mais caros em tabelas clusterizadas do que em tabelas baseadas em heap.

InnoDB requer índices em chaves estrangeiras.