No, eso hace que la relación sea "uno a cero o uno". ¿Es eso lo que realmente necesitas?
Si sí , entonces su "segunda solución" es mejor:
- es más simple,
- requiere menos espacio de almacenamiento (y por lo tanto hace que la memoria caché sea "más grande")
- tiene menos índices que mantener, lo que beneficia la manipulación de datos,
- y (ya que está usando InnoDB) naturalmente grupos los datos, por lo que los usuarios que están cerca también tendrán sus cuentas almacenadas juntas, lo que puede beneficiar la localidad de caché y ciertos tipos de escaneos de rango.
Por cierto, deberá crear accounts.id un número entero ordinario (no de incremento automático) para que esto funcione.
Si no , ver más abajo...
Bueno, "mejor" es una palabra sobrecargada, pero la solución "estándar" sería la misma que en cualquier otra base de datos:poner ambas entidades (usuario y cuenta en su caso) en la misma tabla física.
Teóricamente, podría hacer FK circulares entre los dos PK, pero eso requeriría diferido restricciones para resolver el problema del huevo y la gallina, que desafortunadamente no son compatibles con MySQL.
No tengo mucha experiencia práctica con esa herramienta de modelado en particular, pero supongo que es porque es "uno a muchos" donde el lado "muchos" se limitó a 1 al hacerlo único. Recuerde que "muchos" no significa "1 o muchos", significa "0 o muchos", por lo que la versión "limitada" realmente significa "0 o 1".
No solo en el gasto de almacenamiento para el campo adicional, sino también para el índice secundario. Y dado que está utilizando InnoDB que siempre agrupa tablas , tenga en cuenta que los índices secundarios son incluso más caros en tablas agrupadas que en tablas basadas en montón.
InnoDB requiere índices en claves foráneas.
