Este dilema se puede solucionar de diversas maneras, pero nosotros te compartimos la resolución más completa en nuestra opinión.
Solución:
Dado que las claves primarias son ÚNICAS por defecto, esto hace que esta relación sea uno a uno.
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 mas simple,
- requiere menos almacenamiento1 (y por lo tanto hace que el caché sea “más grande”)
- tiene menos índices que mantener2que beneficia la manipulación de datos,
- y (ya que está utilizando InnoDB) agrupa naturalmente 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, tendrás que hacer accounts.id un entero ordinario (no de incremento automático) para que esto funcione.
Si novea abajo…
¿Cuál es la mejor manera de crear una relación uno a uno en MySQL?
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.
¿Hay otras soluciones además de estas dos?
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.
Y si importo cualquiera de estas soluciones en el diagrama EER de MySQL Workbench, reconoce las relaciones como uno a muchos: S Eso también es confuso.
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”.
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 aún más caros en las tablas agrupadas que en las tablas basadas en montón.
2 InnoDB requiere índices en extranjeros keys.
Su primer enfoque crea dos candidatos keys en la tabla de cuentas: id y user_id.
Por lo tanto, sugiero el segundo enfoque, es decir, usar el extranjero key como el principal key. Este:
- usa una columna menos
- le permite identificar de forma única cada fila
- le permite hacer coincidir la cuenta con el usuario
valoraciones y comentarios
Finalizando este artículo puedes encontrar las críticas de otros desarrolladores, tú aún puedes dejar el tuyo si dominas el tema.