Bagaimanakah Pelbagai Rujukan Utama Asing kepada Lajur Tunggal Boleh Dikendalikan dalam Reka Bentuk Pangkalan Data?

Berbilang Rujukan Kunci Asing kepada Lajur Tunggal

Dalam reka bentuk pangkalan data, ia boleh memberi manfaat untuk merujuk satu lajur dalam satu jadual sebagai asing kekunci dalam berbilang jadual lain. Pendekatan ini membolehkan perkaitan data yang lancar dan pengambilan data yang konsisten merentas berbilang entiti.

Pernyataan Masalah

Pertimbangkan senario pangkalan data berikut:

Anda mempunyai jadual dipanggil pdf_created dengan lajur item_type, item_id, dan kuantiti. Setiap baris dalam jadual ini mewakili item yang diekstrak daripada dokumen PDF. Lajur item_type mengenal pasti jenis item (cth., "1" untuk produk, "2" untuk pengepala templat). Lajur item_id merujuk kepada kunci utama jadual item yang sepadan (cth., produk, perkhidmatan, pengepala). Matlamatnya adalah untuk merujuk lajur item_id sebagai kunci asing dalam ketiga-tiga jadual item: produk, perkhidmatan dan pengepala.

Walau bagaimanapun, kod SQL berikut gagal mencipta perhubungan yang diingini:

CREATE TABLE `pdf_created` (
    `id` INT(10) UNSIGNED NOT NULL UNIQUE AUTO_INCREMENT,
    `pdf_id` INT(10) NOT NULL,
    `item_type` INT(3) UNSIGNED NOT NULL,
    `item_id` INT(10) UNSIGNED NOT NULL,
    `quantity` INT(3) NOT NULL,
    PRIMARY KEY (`id`),
    KEY `FK_pdf_id` (`pdf_id`),
    CONSTRAINT `FK_pdf_id` FOREIGN KEY (`pdf_id`) REFERENCES `pdf` (`id`),
    KEY `FK_item_type` (`item_type`),
    CONSTRAINT `FK_item_type` FOREIGN KEY (`item_type`) REFERENCES `item` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
    KEY `FK_item_id` (`item_id`),
    CONSTRAINT `FK_item_id` FOREIGN KEY (`item_id`) REFERENCES `product` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
    CONSTRAINT `FK_item_id` FOREIGN KEY (`item_id`) REFERENCES `service` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
    CONSTRAINT `FK_item_id` FOREIGN KEY (`item_id`) REFERENCES `header` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Sebab Kegagalan

Masalahnya terletak pada pelbagai kekangan kunci asing pada lajur item_id. Kekangan kunci asing memastikan bahawa setiap nilai dalam lajur item_id hadir sebagai nilai kunci utama dalam sekurang-kurangnya satu daripada empat jadual (produk, perkhidmatan, pengepala). Walau bagaimanapun, adalah mustahil untuk menjamin item_id akan sentiasa wujud sebagai kunci utama dalam keempat-empat jadual secara serentak.

Penyelesaian

Walaupun tidak mungkin untuk mencipta berbilang asing kekangan utama pada satu lajur yang merujuk jadual yang berbeza, anda masih boleh menggunakan lajur item_id untuk merujuk tiga jadual item. Alih keluar semua kekangan kunci asing pada lajur item_id dan bergantung pada kod aplikasi untuk menguatkuasakan integriti rujukan:

CREATE TABLE `pdf_created` (
    `id` INT(10) UNSIGNED NOT NULL UNIQUE AUTO_INCREMENT,
    `pdf_id` INT(10) NOT NULL,
    `item_type` INT(3) UNSIGNED NOT NULL,
    `item_id` INT(10) UNSIGNED NOT NULL,
    `quantity` INT(3) NOT NULL,
    PRIMARY KEY (`id`),
    KEY `FK_pdf_id` (`pdf_id`),
    CONSTRAINT `FK_pdf_id` FOREIGN KEY (`pdf_id`) REFERENCES `pdf` (`id`),
    KEY `FK_item_type` (`item_type`),
    CONSTRAINT `FK_item_type` FOREIGN KEY (`item_type`) REFERENCES `item` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Ini membolehkan anda mengekalkan perhubungan data yang diperlukan tanpa memperkenalkan ralat integriti data.

Atas ialah kandungan terperinci Bagaimanakah Pelbagai Rujukan Utama Asing kepada Lajur Tunggal Boleh Dikendalikan dalam Reka Bentuk Pangkalan Data?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!