Разделение таблиц MySQL, который имеет внешние ключи?
Что было бы соответствующим способом сделать это, так как MySQL, очевидно, не обладает этим. Оставить или разделение или внешние ключи из проектирования баз данных не походило бы на хорошую идею мне. Я предположу, что существует обходное решение для этого?
Обновление 03/24:
http://opendba.blogspot.com/2008/10/mysql-partitioned-tables-with-trigger.html
Как обработать внешний ключ при разделении
Спасибо!
2 ответа
Это зависит от того, насколько размер строк в многораздельной таблице является причиной необходимости разделов.
Если размер строки небольшой и причиной разделения является чистое количество строк, то я не уверен, что вам следует делать.
Если размер строки довольно большой, то учли ли вы следующее:
Пусть P будет секционированной таблицей, а F будет таблицей, на которую есть ссылка в потенциальной внешний ключ. Создайте новую таблицу X :
CREATE TABLE `X` (
`P_id` INT UNSIGNED NOT NULL,
-- I'm assuming an INT is adequate, but perhaps
-- you will actually require a BIGINT
`F_id` INT UNSIGNED NOT NULL,
PRIMARY KEY (`P_id`, `F_id`),
CONSTRAINT `Constr_X_P_fk`
FOREIGN KEY `P_fk` (`P_id`) REFERENCES `P`.`id`
ON DELETE CASCADE ON UPDATE RESTRICT,
CONSTRAINT `Constr_X_F_fk`
FOREIGN KEY `F_fk` (`F_id`) REFERENCES `F`.`id`
ON DELETE RESTRICT ON UPDATE RESTRICT
) ENGINE=INNODB CHARACTER SET ascii COLLATE ascii_general_ci
и, что особенно важно, создайте хранимую процедуру для добавления строк в таблицу P . Ваша хранимая процедура должна гарантировать (использовать транзакции), что всякий раз, когда строка добавляется в таблицу P , соответствующая строка добавляется в таблицу X . Вы не должны разрешать добавление строк к P "обычным" способом! Вы можете гарантировать, что ссылочная целостность будет поддерживаться, только если продолжите использовать хранимую процедуру для добавления строк. Однако вы можете свободно удалить из P обычным способом.
Идея заключается в том, что ваша таблица X имеет достаточно маленькие строки, поэтому вам, надеюсь, не нужно разбивать ее, даже если в ней много строк.Я полагаю, что индекс в таблице, тем не менее, займет довольно большой кусок памяти.
Если вам нужно запросить P по внешнему ключу, вы, конечно же, вместо этого запросите X , поскольку именно там на самом деле находится внешний ключ.
Я настоятельно рекомендую сегментирование с использованием даты в качестве ключа для архивирования данных в архивные таблицы. Если вам нужно составить отчет по нескольким архивным таблицам, вы можете использовать представления или встроить логику в свое приложение.
Однако с правильно структурированной БД вы должны иметь возможность обрабатывать десятки миллионов строк в таблице до разделения, иначе сегментирование действительно необходимо.