Изменение первичного ключа MySQL, когда ограничения внешнего ключа существуют
Специальные блоки кода такой как BEGIN, CHECK и END. Они прибывают из Awk, но работают по-другому в Perl, потому что это не основано на записи.
BEGIN блок может использоваться для определения некоторого кода для фазы парсинга; это также выполняется, когда Вы делаете syntax-and-variable-check perl -c. Например, для загрузки в переменных конфигурации:
BEGIN {
eval {
require 'config.local.pl';
};
if ($@) {
require 'config.default.pl';
}
}
2 ответа
Добавьте индекс (он может быть даже УНИКАЛЬНЫМ) в old_pk перед удалением первичного ключа:
mysql> CREATE TABLE parent (
-> old_pk CHAR(8) NOT NULL PRIMARY KEY
-> ) ENGINE=InnoDB;
Query OK, 0 rows affected (0.00 sec)
mysql> CREATE TABLE child (
-> parent_key CHAR(8),
-> FOREIGN KEY (parent_key) REFERENCES parent(old_pk)
-> ON UPDATE CASCADE ON DELETE CASCADE
-> ) ENGINE=InnoDB;
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO parent VALUES ('a');
Query OK, 1 row affected (0.01 sec)
mysql> CREATE INDEX old_pk_unique ON parent (old_pk);
Query OK, 1 row affected (0.01 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> ALTER TABLE parent DROP PRIMARY KEY;
Query OK, 1 row affected (0.01 sec)
Records: 1 Duplicates: 0 Warnings: 0
mysql> INSERT INTO child VALUES ('a');
Query OK, 1 row affected (0.00 sec)
mysql> SHOW CREATE TABLE parent;
+--------+------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+--------+------------------------------------------------------------------------------------------------------------------------------+
| parent | CREATE TABLE `parent` (
`old_pk` char(8) NOT NULL,
KEY `old_pk_unique` (`old_pk`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
+--------+------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> INSERT INTO child VALUES ('b');
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`test/child`, CONSTRAINT `child_ibfk_1` FOREIGN KEY (`parent_key`) REFERENCES `parent` (`old_pk`) ON DELETE CASCADE ON UPDATE CASCADE)
mysql> INSERT INTO parent VALUES ('b');
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO child VALUES ('b');
Query OK, 1 row affected (0.01 sec)
mysql> ALTER TABLE parent ADD id INT;
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0
mysql> UPDATE parent SET id = 1 WHERE old_pk = 'a';
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> UPDATE parent SET id = 2 WHERE old_pk = 'b';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> ALTER TABLE parent ADD PRIMARY KEY (id);
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0
mysql> SHOW CREATE TABLE parent;
+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| parent | CREATE TABLE `parent` (
`old_pk` char(8) NOT NULL,
`id` int(11) NOT NULL default '0',
PRIMARY KEY (`id`),
KEY `old_pk_unique` (`old_pk`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
Я взвесу это, сделав то, что может быть непопулярным предложением. Не используйте ограничения внешнего ключа в своей базе данных - при необходимости применяйте уникальный ключ и другие ограничения через TSQL в хранимых процедурах. По моему опыту, в масштабируемых средах проверочные ограничения используются редко.
Я говорю это без предвзятого отношения к противоположным комментариям / обсуждениям, которые могут последовать. Я не говорю, что это предложение правильное, просто это преобладающее мнение в магазинах, в которых я работал.
Просьба: Если вы проголосовали против меня, пожалуйста, также оставьте короткий комментарий. За 10 или около того лет я работал с реляционными базами данных, и единственные люди, которых я знаю, кто использует проверочные ограничения, работают над системами, которые не имеют большого масштаба. Если это те люди, которые голосуют против меня, я могу с этим жить.