tengo las siguientes 2 tablas en MySQL: Cliente (id, nombre, apellido ...) de experiencia (Id, CustomerId, Valor, ...)En una relación uno a uno, ¿debo soltar una de las columnas de identificación de la tabla?
La relación es uno a uno, cada el cliente solo tiene una bonificación. (CustomerId es único en la Tabla de bonificación)
P: ¿Debo soltar la columna Id de la tabla de Bonus? (Quiero saber por qué o por qué no)
me quite el coulmn Bonus.Id y hacer Bonus.CustomerId el PK. Hacer esto eliminará la necesidad de tener una restricción única en la columna Bonus.CustomerId, ya que ahora será un PK. Cualquiera que mire la mesa verá el one-to-one más claramente sin la Bonificación. Podría hacerlo. No necesitará un índice en Bonus.CustomerId, el índice PK será todo lo que necesita, por lo que se desperdiciará menos espacio en disco y caché de memoria. Además, si alguna vez necesita un FK para la tabla de Bonus, usted usaría el valor CustomerId (el nuevo PK), que puede usarse para volver a las tablas de Cliente o Bonificación, no solo a Bonus.
si es uno a uno, ¿por qué hay una mesa extra? en su lugar, puede poner "bonusvalue" en su tabla de clientes.
(otra cosa: sí, se puede eliminar el ID del bono-mesa, el id-cliente es la clave principal y el "id" es completamente redundante)
una relación uno-a-uno es buena cuando la mayoría de las filas de la tabla principal no necesitan una fila en absoluto en la segunda tabla. Por ejemplo, tiene una tabla principal de "Persona" y luego una tabla uno a uno "DoctorInfo" y otra uno a uno "StudentInfo", etc. No le conviene incluir todas las columnas DoctorInfo o StudentInfo en persona"? Yo no, los dividiría en mesas uno a uno. –
También divide las tablas en una de uno a uno cuando la longitud de la fila de la tabla es demasiado grande para un acceso eficiente. O si los datos raramente serán consultados y la tabla principal será frecuentemente consultada. O de usted quiere limitar la visibilidad de los datos. – HLGEM
Es redundante, pero no estoy de acuerdo con poner todo en una tabla, ¿qué pasa con la dirección, incluso si se trata de una a una. Me gusta hacer mis tablas como hago con mis objetos, solo necesito tenerlas. Tantas clases/tablas como necesito. – Vlad
Supongo que no es realmente un verdadero one-to-one porque presumiblemente podría tener un cliente sin una fila de bonificación. Las restricciones de clave externa de estilo SQL son siempre opcionales en el lado de referencia de cualquier relación.
Acepto que la columna de Bonus.Id parece ser completamente redundante.
Tiene razón, no todos los clientes tienen una bonificación. – Vlad
Gracias por los comentarios, normalmente agrego una columna de id a todas las tablas que creo y no pienso demasiado, pero comencé a discutir sobre esto con un colega mío que me sugirió que lo dejara. Quería obtener más opiniones sobre el tema antes de hacerlo. – Vlad