删除时外键约束一对多表,更新级联规则

Foreign Key constraint one to many tables while on delete ,on update cascade rule

我正在开发一个 Web 应用程序,但我遇到了数据库问题。

我有三个table:如下

Table 1:

CREATE TABLE mydb.emp(  
    eID INT NOT NULL,  
    eName VARCHAR(45) NULL,  
    PRIMARY KEY(eID)  
);

Table 2:

CREATE TABLE mydb.empLocation(  
    eLocateID INT NOT NULL,
    eArea VARCHAR(45) NULL,    
    eCity VARCHAR(45) NULL,  
    eZipcode VARCHAR(45) NULL,
    eID INT NULL,  
    PRIMARY KEY(eLocateID),
    CONSTRAINT eID
        FOREIGN KEY (eID)
        REFERENCES mydb.emp(eID)
        ON DELETE CASCADE
        ON UPDATE CASCADE
);

Table 3:

CREATE TABLE mydb.empLogin(  
    eLoginID INT NOT NULL,
    eTimeIn TIMESTAMP NULL,    
    eTimeOut TIMESTAMP NULL,  
    eID INT NULL,  
    PRIMARY KEY(eLoginID),
    CONSTRAINT eID
        FOREIGN KEY (eID)
        REFERENCES mydb.emp(eID)
        ON DELETE CASCADE
        ON UPDATE CASCADE
);

当我创建 table 3 时出现问题,我无法插入 table,因为在删除和更新级联时。

我想要级联,因为当我在我的 emp table 中删除一行时,其他 table 中的数据也应该被删除。

请给我这个问题的任何解决方案或这个用例的任何替代解决方案,提前致谢。

请尝试以下操作:

Table 1

CREATE TABLE emp(  
       eID INT NOT NULL,  
       eName VARCHAR(45) NULL,  
       PRIMARY KEY(eID)  
);


Table 2

CREATE TABLE empLocation(  
       eLocateID INT NOT NULL,
       eArea VARCHAR(45) NULL,    
       eCity VARCHAR(45) NULL,  
       eZipcode VARCHAR(45) NULL,
       eID INT NULL,  
       PRIMARY KEY(eLocateID),
       CONSTRAINT eID
           FOREIGN KEY (eID)
           REFERENCES emp(eID)
              ON DELETE CASCADE
              ON UPDATE CASCADE
);


Table 3

CREATE TABLE empLogin(  
       eLoginID INT NOT NULL,
       eTimeIn TIMESTAMP NULL,    
       eTimeOut TIMESTAMP NULL,  
       eID INT NULL,  
       PRIMARY KEY(eLoginID)
);

ALTER TABLE empLogin ADD FOREIGN KEY (eID) REFERENCES emp(eID) 
            ON DELETE CASCADE 
            ON UPDATE CASCADE;

然后,

INSERT INTO emp VALUES(1, 'John'), (2, 'Paul');
INSERT INTO empLogin VALUES
    (1, '2017-01-27 09:00:00', '2017-01-27 18:00:00', 1),
    (2, '2017-01-27 09:30:00', '2017-01-27 18:30:00', 2);

这种方式似乎工作得很好。