Het hangt af van de mate waarin de grootte van de rijen in de gepartitioneerde tabel de reden is dat partities nodig zijn.
Als de rijgrootte klein is en de reden voor partitionering het enkele getal is rijen, dan weet ik niet zeker wat u moet doen.
Als de rijgrootte vrij groot is, heb je dan het volgende overwogen:
Laat P de gepartitioneerde tabel zijn en F de tabel zijn waarnaar wordt verwezen in de toekomstige externe sleutel. Maak een nieuwe tabel 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
en cruciaal, maak een opgeslagen procedure voor het toevoegen van rijen aan tabel P . Uw opgeslagen procedure moet ervoor zorgen (gebruik transacties) dat wanneer een rij wordt toegevoegd aan tabel P , wordt een bijbehorende rij toegevoegd aan tabel X . U mag niet toestaan dat rijen worden toegevoegd aan P op de "normale" manier! U kunt alleen garanderen dat de referentiële integriteit behouden blijft als u uw opgeslagen procedure voor het toevoegen van rijen blijft gebruiken. U kunt vrijelijk verwijderen uit P op de normale manier.
Het idee hier is dat uw tabel X heeft voldoende kleine rijen die u hopelijk niet hoeft te partitioneren, ook al heeft het veel rijen. De index op de tafel zal niettemin een behoorlijk groot deel van het geheugen in beslag nemen, denk ik.
Mocht u P . moeten opvragen op de refererende sleutel, vraag je natuurlijk X in plaats daarvan, want daar is de externe sleutel eigenlijk.