Доброго времени суток, LOR.
Есть дурацкий вопрос по индексам, но сначала преамбула:
Потихоньку пилится база данных с двумя таблицами: «сущности» и «связи».
«Сущности» - это плоский список заметок с уникальными заголовками и произвольным содержанием:
CREATE TABLE `entities` (
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'Номер по порядку',
`created` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Дата/время создания',
`modified` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'Дата/время изменения',
`title` VARCHAR(255) NOT NULL COMMENT 'Заголовок заметки',
`content` MEDIUMTEXT NOT NULL COMMENT 'Текст заметки',
PRIMARY KEY (`id`),
UNIQUE INDEX `title` (`title`)
)
COMMENT='Сущности. /*TODO: Реализовать резервное копирование изменяемых записей*/'
COLLATE='utf8_general_ci'
ENGINE=InnoDB
AUTO_INCREMENT=7
;«Связи», как подсказывает К.О., соединяют заметки из первой таблицы по принципу «многие ко многим»:
CREATE TABLE `relations` (
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 'Номер по порядку',
`created` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Дата/время создания',
`from` INT(10) UNSIGNED NOT NULL COMMENT 'Источник связи',
`to` INT(10) UNSIGNED NOT NULL COMMENT 'Назначение связи',
PRIMARY KEY (`id`),
UNIQUE INDEX `LINK` (`from`, `to`),
INDEX `FK_from` (`from`),
INDEX `FK_to` (`to`),
CONSTRAINT `FK_from` FOREIGN KEY (`from`) REFERENCES `entities` (`id`) ON UPDATE NO ACTION ON DELETE CASCADE,
CONSTRAINT `FK_to` FOREIGN KEY (`to`) REFERENCES `entities` (`id`) ON UPDATE NO ACTION ON DELETE CASCADE
)
COMMENT='Связи. /*TODO: Реализовать резервное копирование удаляемых записей!!!*/'
COLLATE='utf8_general_ci'
ENGINE=InnoDB
AUTO_INCREMENT=12
;Связи получаются направленные, типа «1->2», «2->4», «3->2», «4->1», и т.д. В итоге выходит нормальный такой ориентированный граф. Проблема в том, что он мне не нужен. Точнее, нужен, но не ориентированный, а простой, без направленных связей. Я, конечно, могу игнорировать направление связи и представлять её как «1-2», «2-4», «3-2», «4-1»...
Но появляется, собственно, фабула: связи «1->2» и «2->1» для MySQL разные и это естественно. Так что UNIQUE INDEX `LINK` (`from`, `to`) мне явно недостаточно, чтобы исключить возможность появления логических дублей существующих связей. И вот тут я залипаю...
Как проще всего избежать появления «противонаправленных» связей?
------------
Решено: Мой вариант
