Cuándo utilizar “ON UPDATE CASCADE”

StackOverflow https://stackoverflow.com/questions/1481476

Pregunta

Yo uso "ON DELETE CASCADE" regularmente, pero nunca uso "ON UPDATE CASCADE" ya que no estoy tan seguro de en qué situación será útil.

En aras de la discusión vamos a ver algo de código. 

CREATE TABLE parent (
    id INT NOT NULL AUTO_INCREMENT,
    PRIMARY KEY (id)
);

CREATE TABLE child (
    id INT NOT NULL AUTO_INCREMENT, parent_id INT,
    INDEX par_ind (parent_id),
    FOREIGN KEY (parent_id)
        REFERENCES parent(id)
        ON DELETE CASCADE
);

Para "ON DELETE CASCADE", si se elimina un padre con un id, un registro en el niño con parent_id = parent.id se borrará automáticamente. Esto no debería ser un problema.

  1. Esto significa que "ON UPDATE CASCADE" va a hacer lo mismo cuando se actualiza id de los padres?

  2. Si (1) es cierto, significa que no hay necesidad de usar "ON UPDATE CASCADE" si parent.id no es actualizable (o nunca se actualiza) como cuando es AUTO_INCREMENT o siempre dispuesto a ser TIMESTAMP . Es correcto eso?

  3. Si (2) No es cierto, en lo que otro tipo de situación debemos usar "ON UPDATE CASCADE"?

  4. ¿Qué pasa si (por alguna razón) actualizar el child.parent_id ser algo no existente, entonces se eliminará automáticamente?

Bueno, lo sé, algunos de la pregunta anterior puede estar la prueba programmically de entender pero quiero también saber si algo de esto es proveedor de base de datos dependiente o no.

Por favor, arrojar algo de luz.

¿Fue útil?

Solución

Es cierto que si su clave primaria es sólo un valor de identidad de auto incrementa, tendría ninguna utilidad real para EN Actualizar en cascada.

Sin embargo, digamos que la clave principal es un código de barras UPC de 10 dígitos y debido a la expansión, es necesario cambiarlo a un código de barras UPC de 13 dígitos. En ese caso, ON UPDATE CASCADE permitiría cambiar el valor de la clave primaria y todas las tablas que tienen referencias de claves externas con el valor será cambiado en consecuencia.

En referencia a # 4, si cambia el ID de niño a algo que no existe en la tabla primaria (y usted tiene la integridad referencial), usted debe conseguir un error de clave externa.

Otros consejos

  1. Sí, esto significa que, por ejemplo, si lo hace UPDATE parent SET id = 20 WHERE id = 10 todos los niños de parent_id de 10 también serán actualizados a 20

  2. Si no actualiza el campo de la clave externa se refiere, no es necesaria esta configuración

  3. No se puede pensar en cualquier otro uso.

  4. No se puede hacer que a medida que la restricción de clave externa sería un fracaso.

Creo que se ha clavado más o menos los puntos!

Si usted sigue las mejores prácticas de diseño de bases de datos y su clave primaria no es actualizable (que creo que siempre debe ser el caso de todos modos), entonces nunca realmente necesita la cláusula ON UPDATE CASCADE.

Zed hizo un buen punto, que si se utiliza una clave naturales (por ejemplo, un campo regular de su tabla de base de datos) como clave primaria, es posible que haya cierta situaciones donde se necesita para actualizar sus claves primarias. Otro ejemplo reciente sería el ISBN (Número Internacional Normalizado del libro) que pasó de 10 a 13 dígitos Hace + caracteres no demasiado largo.

Este no es el caso si usted elige utilizar sustituto (por ejemplo artificialmente generadas por el sistema) teclas como la clave principal (que sería mi opción preferida en todo menos en las más raras ocasiones).

Así que al final: si su clave primaria nunca cambia, entonces nunca necesitan la cláusula ON UPDATE CASCADE

.

Marc

Hace unos días he tenido un problema con los factores desencadenantes, y me he dado cuenta de que ON UPDATE CASCADE puede ser útil. Echar un vistazo en este ejemplo (PostgreSQL): 

CREATE TABLE club
(
    key SERIAL PRIMARY KEY,
    name TEXT UNIQUE
);

CREATE TABLE band
(
    key SERIAL PRIMARY KEY,
    name TEXT UNIQUE
);

CREATE TABLE concert
(
    key SERIAL PRIMARY KEY,
    club_name TEXT REFERENCES club(name) ON UPDATE CASCADE,
    band_name TEXT REFERENCES band(name) ON UPDATE CASCADE,
    concert_date DATE
);

En mi problema que tuve para definir algunas operaciones adicionales (disparador) para actualizar la tabla de concierto. Estas operaciones tuvieron que modificar club_name y band_name. No he podido hacerlo, porque de referencia. No podría modificar concierto y después ocuparse de tablas del club y de la banda. No podría también hacerlo a la inversa. ON UPDATE CASCADE fue la clave para resolver el problema.

Mi comentario es sobre todo en referencia al punto # 3: ¿en qué circunstancias es EN Actualizar en cascada aplicable si estamos asumiendo que la clave principal no es actualizable? Este es uno de los casos.

Estoy tratando con un escenario de replicación en el que múltiples bases de datos del satélite necesitan ser fusionado con un maestro. Cada satélite está generando datos sobre las mismas tablas, por lo que la fusión de las tablas para el maestro lleva a violaciónes de la restricción de unicidad. Estoy tratando de utilizar ON UPDATE CASCADE como parte de una solución en la que las llaves re-incremento durante cada combinación. ON UPDATE CASCADE debería simplificar este proceso mediante la automatización de parte del proceso.

Es una excelente pregunta, que tenía la misma pregunta ayer. Pensé acerca de este problema, buscó específicamente si existía algo así como "ON UPDATE CASCADE" y, afortunadamente, los diseñadores de SQL también había pensado en eso. Estoy de acuerdo con Ted.strauss, y también les comentaba el caso de Noran.

¿Cuándo se utiliza? Como Ted señaló, cuando se está tratando a varias bases de datos a la vez, y la modificación en una de ellas, en una mesa, tiene todo tipo de reproducción en lo que Ted llama "base de datos de satélite", no se puede mantener con el muy original Identificación y por alguna razón usted tiene que crear uno nuevo, en caso de que no se puede actualizar los datos de la anterior (por ejemplo, debido a los permisos, o en caso que está buscando para la solidez en un caso que es tan efímera que no merece el respeto absoluto y total de las normas totales de normalización, simplemente porque habrá una vida muy corta utilidad)

Por lo tanto, estoy de acuerdo en dos puntos:

(A). Sí, en muchas ocasiones un mejor diseño puede evitarlo; PERO

(B). En los casos de migraciones, replicando bases de datos, o resolver situaciones de emergencia, es una gran herramienta que, afortunadamente, estaba allí cuando fui a buscar si existiera.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top