Я не уверен, как бы вы сделали это без огромной, ужасной избыточности. Стандартный способ обработки отношения «многие ко многим» между двумя таблицами - через третью таблицу, которая содержит два значения первичного ключа, одно для первой таблицы, одно для второй таблицы, с уникальным ограничением (читай «индекс») на комбинация всех этих столбцов и, возможно, с одним или двумя дублирующимися (неуникальными) индексами на отдельных первичных ключах. В общих чертах:
CREATE TABLE Table1 (pkcol1 ... PRIMARY KEY, ...);
CREATE TABLE Table2 (pkcol2 ... PRIMARY KEY, ...);
CREATE TABLE MtoM_Table1_Table2
(
pkcol1 ... REFERENCES Table1,
pkcol2 ... REFERENCES Table2,
PRIMARY KEY (pkcol1, pkcol2)
);
-- CREATE INDEX fk1_mtom_table1_table2 ON MtoM_Table1_Table2(pkcol1);
-- CREATE INDEX fk2_mtom_table1_table2 ON MtoM_Table1_Table2(pkcol2);
Если ваша СУБД интеллектуальна, вы можете пропустить отдельный индекс в первом столбце первичного ключа, поскольку индекс в первичном ключе также можно использовать при поиске только начального значения.
Предположим, что Table1 и Table2 - это одна и та же таблица (так что, фактически, у нас есть только Table1), как в вопросе; для этого обычно требуется таблица сопоставления MtoM_Table1_Table1 - отдельная таблица из основной таблицы. Таблица сопоставления должна иметь отдельные имена для столбца PK (первичный ключ), но оба столбца (или наборы столбцов) в таблице сопоставления будут ссылаться на столбец (столбцы) PK в таблице 1.
CREATE TABLE Table1 (pkcol1 ... PRIMARY KEY, ...);
CREATE TABLE MtoM_Table1_Table1
(
pkcol1 ... REFERENCES Table1(pkcol1),
akcol1 ... REFERENCES Table1(pkcol1),
PRIMARY KEY (pkcol1, akcol1)
);
-- CREATE INDEX fk1_mtom_table1_table1 ON MtoM_Table1_Table1(pkcol1);
-- CREATE INDEX fk2_mtom_table1_table1 ON MtoM_Table1_Table1(akcol1);
Если вы тоже хотите исключить таблицу сопоставления, то вам потребуется второй столбец в таблице Table1 для хранения другого значения PK - назовите его FKcol1 (для столбца внешнего ключа). Это оставляет вас в затруднительном положении: каков первичный ключ? Это должна быть комбинация PKCol1 и FKCol1. Но FKCol1 должен ссылаться на первичный ключ другой строки - поэтому у вас есть противоречие. Даже если предположить, что вам удалось избежать этой проблемы (как, собственно,?), Иметь «много строк» в ссылочной стороне отношения «многие ко многим», вы должны иметь несколько строк в основной таблице с одинаковыми данными в все столбцы, кроме FKcol, но они будут ссылаться на число (в общем, более одной) других строк таблицы. Это противоречие, плюс кошмар избыточности, плюс вы потеряли свой простой первичный ключ, плюс было бы ужасно понять, что, черт возьми, происходит.
CREATE TABLE Table1
(
pkcol1 ... /* PRIMARY KEY */,
fkcol1 ... /* FOREIGN KEY REFERENCES Table1(pkcol1) */,
...
);
-- CREATE INDEX fk1_table1 ON Table1(pkcol1);
-- CREATE INDEX fk2_table1 ON Table1(fkcol1);
Итак, я убежден, что единственный вменяемый ответ: «Нет - вы не можете представить оба конца отношения« многие ко многим »в одной таблице; вы должны использовать таблицу сопоставления, чтобы сохранить большие шансы на что-либо работающее». как обычно "в системе".