2011-12-17 12 views
5

Estoy tratando de crear uno a muchos relación usando una tabla. ¿Esto es posible?uno a muchos con una tabla

create table user(id int primary key auto_increment not null,                              
created_by int default null                                       
)ENGINE=INNODB;                                          

alter table user add foreign key (created_by) references user(id) ON DELETE SET NULL ON UPDATE CASCADE;                    

insert into user (id) VALUES(1);                                     
insert into user (id, created_by) VALUES (2,1); 

Ahora cuando se borra el usuario con id = 1 el valor de created_by de forma automática cambiar a NULL como lo esperaba.

Pero cuando cambio id del usuario con id = 1 me sale este error

mysql> update user set id=2 where id=1; 
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`jrt`.`user`, CONSTRAINT `user_ibfk_1` FOREIGN KEY (`created_by`) REFERENCES `user` (`id`) ON DELETE SET NULL ON UPDATE CASCADE) 

¿Cómo puedo solucionar este problema? Afirme esta actualización Quiero que la columna created_by se cambie en cascada.

+0

¿Dónde se necesita un concepto? - Sólo curioso. – Lion

+0

No lo necesito en absoluto. Tengo curiosidad. – mecio

+0

Tim Gee une un hilo del foro con la respuesta exacta (es un mecanismo simple para evitar bucles infinitos), asegúrese de leer [el seguimiento] (http://forums.mysql.com/read.php?136,391782,398085 # msg-398085). –

Respuesta

2

llaves no están destinados a ser cambiado, que están destinados a ser 'identificar'. Por lo tanto, el usuario con id 2 es lógicamente un usuario diferente con usuario con id 1. En el momento en que crea un usuario único, su clave principal debe ser la misma durante la vida de ese usuario.

Así que esto es realmente un problema de diseño. Debe preguntar por qué desea cambiar la identificación de un usuario en particular. Puede ser que lo que desea sea una clave de identificación fija Y otro identificador (que no es la clave y existe únicamente en la tabla de usuarios) que puede cambiar.

[Actualizado con más información] Aquí hay un recurso (hay muchos disponibles en línea) sobre los fundamentos del diseño de bases de datos relacionales. http://www.deeptraining.com/litwin/dbdesign/FundamentalsOfRelationalDatabaseDesign.aspx

La sección pertinente es "Tablas, la singularidad y llaves".

Fabian Pascal, en su SQL libro y relacionales Fundamentos, señala que la decisión debe basarse en los principios de minimalidad (elija las columnas menor cantidad necesaria), estabilidad (elegir una clave que pocas veces cambios), y simplicidad/familiaridad (elija una clave que sea simple y familiar para los usuarios).

Personalmente, iría más allá en la estabilidad; intenta elegir una clave que nunca cambia. Por ejemplo, "correo electrónico" sería una mala elección de clave para un usuario ya que el usuario puede cambiar su correo electrónico. Si elige una clave, tales como un número generado internamente o tal vez un identificador único del sistema de personal, entonces no siempre tienen que preocuparse de que el cambio y la migración de este cambio a otras tablas.

Nota: puede haber casos en los que como un "excepcional" que necesita para cambiar una clave principal. Esto se realiza mejor con unas pocas sentencias SQL manuales (elimina el primer usuario y crea un segundo usuario idéntico con una clave diferente). Sin embargo, no debería formar parte del diseño de la base de datos, lo que implica la naturaleza automatizada de una actualización en cascada.

SEE ALSO:When to use "ON UPDATE CASCADE"

también NOTA:http://forums.mysql.com/read.php?136,391782,391782

+0

Estaba pensando en 'actualizar el usuario set id = 5 donde id = 1;' – mecio

+0

Digamos que tenemos dirección de correo electrónico en lugar de identificación. El usuario desea colgar su correo electrónico y también es la clave principal de la tabla, como en el ejemplo anterior. – mecio

+0

Sí, eso es un mal diseño de la base de datos y, por lo tanto, no existe una forma automática de realizar una cascada de dicho cambio porque no debería hacerlo. Actualizaré mi respuesta para proporcionar un recurso externo con aclaración. –

Cuestiones relacionadas