いいえ、それは関係を「1対0または1」にします。それはあなたが実際に必要としているものですか？
はいの場合 、それならあなたの「2番目の解決策」がより良いです：
- もっと簡単です
- 必要なストレージが少なくなります（したがって、キャッシュが「大きく」なります）
- 維持するインデックスが少なくなるため、データ操作に役立ちます。
- および（InnoDBを使用しているため）当然クラスター データが近くにあるため、近くにいるユーザーはアカウントも近くに保存されます。これにより、キャッシュの局所性と特定の種類の範囲スキャンに役立つ可能性があります。
ところで、accounts.idを作成する必要があります これが機能するための通常の整数（自動インクリメントではない）。
いいえの場合 、以下を参照してください...
「最良」はオーバーロードされた単語ですが、「標準」ソリューションは他のデータベースと同じです。両方のエンティティ（この場合はユーザーとアカウント）を同じ物理テーブルに配置します。
理論的には、2つのPK間で循環FKを作成できますが、その場合は延期する必要があります。 残念ながらMySQLではサポートされていない鶏と卵の問題を解決するための制約。
その特定のモデリングツールについてはあまり実用的な経験はありませんが、それは「多」側をユニークにすることで「多」側を1に制限した「1対多」だからだと思います。 「多く」は「1つ以上」を意味するのではなく、「0以上」を意味するため、「上限付き」バージョンは実際には「0または1」を意味することに注意してください。
追加フィールドの保管費用だけでなく、セカンダリインデックスの保管費用も含まれます。また、常にテーブルをクラスター化する InnoDBを使用しているため 、セカンダリインデックスは、ヒープベースのテーブルよりもクラスタ化されたテーブルの方がコストがかかることに注意してください。
InnoDB インデックスが必要> 外部キーについて。