相关疑难解决方法(0)

我经常使用"ON DELETE CASCADE",但我从不使用"ON UPDATE CASCADE",因为我不太确定在什么情况下它会有用.

为了便于讨论,请看一些代码.

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
);

对于"ON DELETE CASCADE",如果id删除了具有a的父级,parent_id = parent.id则将自动删除子级中的记录.这应该没问题.

1. 这意味着当id更新父级时,"ON UPDATE CASCADE"会做同样的事情吗？

2. 如果(1)为真,则意味着如果parent.id不可更新(或永远不会更新),则不需要使用"ON UPDATE CASCADE",就像它是AUTO_INCREMENT或者总是设置为TIMESTAMP.是对的吗？

3. 如果(2)不成立,在其他什么情况下我们应该使用"ON UPDATE CASCADE"？

4. 如果我(由于某种原因)更新了child.parent_id不存在的内容,它会被自动删除吗？

好吧,我知道,上面的一些问题可以通过程序测试来理解,但我也想知道这是否依赖于数据库供应商.

请说清楚.

关于这个答案,我偶然发现了一个我无法解释的现象.

版本:
x86_64-unknown-linux-gnu上的PostgreSQL 9.1.2,由gcc-4.4.real编译(Debian 4.4.5-8)4.4.5,64位

请考虑以下演示.测试平台:

CREATE TEMP TABLE t (
  id  integer
 ,txt text
 ,CONSTRAINT t_pkey PRIMARY KEY (id) DEFERRABLE INITIALLY IMMEDIATE
);

INSERT INTO t VALUES
 (1, 'one')
,(2, 'two');

1)修改多行的UPDATE语句:

UPDATE t
SET    id = t_old.id
FROM   t t_old
WHERE (t.id, t_old.id) IN ((1,2), (2,1));

目前的实施似乎有一个错误？上面的UPDATE虽然不应该有效.约束已定义INITIALLY IMMEDIATE,我没有使用SET CONSTRAINTS.

我错过了什么,或者这是一个(相当无害)的错误？

2)数据修改CTE

因此,修改CTE的数据也可以工作,尽管它有一个NOT DEFERREDpk 失败:

WITH x AS (
    UPDATE t SET id = 1 WHERE id = 2 …