sql >> Base de Datos >  >> RDS >> Mysql

MySQL - ¿Relación uno a uno?

No, eso hace que la relación sea "uno a cero o uno". ¿Es eso lo que realmente necesitas?

Si , 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.