Es hängt davon ab, inwieweit die Größe der Zeilen in der partitionierten Tabelle der Grund dafür ist, dass Partitionen erforderlich sind.
Wenn die Zeilengröße klein ist und der Grund für die Partitionierung die reine Anzahl ist Zeilen, dann bin ich mir nicht sicher, was Sie tun sollten.
Wenn die Zeilengröße ziemlich groß ist, haben Sie Folgendes berücksichtigt:
Lassen Sie P sei die partitionierte Tabelle und F die Tabelle sein, auf die im Möchtegern-Fremdschlüssel verwiesen wird. Erstellen Sie eine neue Tabelle 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
Erstellen Sie vor allem eine gespeicherte Prozedur zum Hinzufügen von Zeilen zur Tabelle P . Ihre gespeicherte Prozedur sollte sicherstellen (Transaktionen verwenden), dass immer dann, wenn eine Zeile zur Tabelle P hinzugefügt wird , wird der Tabelle X eine entsprechende Zeile hinzugefügt . Sie dürfen nicht zulassen, dass Zeilen zu P hinzugefügt werden auf die "normale" Weise! Sie können nur garantieren, dass die referentielle Integrität aufrechterhalten wird, wenn Sie weiterhin Ihre gespeicherte Prozedur zum Hinzufügen von Zeilen verwenden. Sie können frei aus P löschen aber ganz normal.
Die Idee dabei ist, dass Ihre Tabelle X hat ausreichend kleine Zeilen, so dass Sie es hoffentlich nicht partitionieren müssen, obwohl es viele, viele Zeilen hat. Der Index auf der Tabelle wird dennoch einen ziemlich großen Teil des Speichers einnehmen, denke ich.
Sollten Sie P abfragen müssen auf dem Fremdschlüssel fragen Sie natürlich X ab stattdessen, da sich dort tatsächlich der Fremdschlüssel befindet.
