Проблема в том, что ваш второй NODEID CONSTRAINT перезаписывает первый.
Это полиморфное отношение, которое вы хотите создать, поэтому одно из возможных решений, которое все еще использует преимущества ограничений внешнего ключа базы данных, заключается в использованииполиморфный «supertable» для mainnodes
и subnodes
, называемый чем-то вроде nodes
:
CREATE TABLE IF NOT EXISTS `database`.`nodes` (
`ID` INT(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`ID`))
Затем пусть каждая из ваших «subtables» ссылается на это с помощью ограничения внешнего ключа:
CREATE TABLE IF NOT EXISTS `database`.`mainnodes` (
...
`NODEID` INT(11) NOT NULL,
CONSTRAINT `MAINNODE_NODE_RELATIONSHIP`
FOREIGN KEY (`NODEID` )
REFERENCES `database`.`nodes` (`ID` )
ON DELETE CASCADE,
...)
CREATE TABLE IF NOT EXISTS `database`.`subnodes` (
...
`NODEID` INT(11) NOT NULL,
CONSTRAINT `SUBNODE_NODE_RELATIONSHIP`
FOREIGN KEY (`NODEID` )
REFERENCES `database`.`nodes` (`ID` )
ON DELETE CASCADE,
...)
Наконец, ваша таблица tagrelationship
может просто ссылаться на супертаблицу, nodes
:
CREATE TABLE IF NOT EXISTS `database`.`tagrelationship` (
...
CONSTRAINT `TAGS_AGRELATIONSHIP`
FOREIGN KEY (`TAGID` )
REFERENCES `database`.`tags` (`ID` )
ON DELETE CASCADE,
CONSTRAINT `NODES_CMSTAGRELATIONSHIP`
FOREIGN KEY (`NODEID` )
REFERENCES `database`.`nodes` (`ID` )
ON DELETE CASCADE,
...)
Простое, но менее надежное решение состоит в том, чтобы просто удалить последние два ограничения относительно того, на что может ссылаться NODEID.и используйте код своего приложения, чтобы применить ограничение.