Может ли кто-нибудь сразу увидеть проблему или узкое место в схеме ниже? Чтение - это 90% операций, но я бы хотел знать, стреляю ли я себе в ногу в любом месте при записи.
Предложение
Каждый объект (строка в другой таблице) может быть связан с другими объектами. Для каждой пары отношений может быть только одна запись (пары чувствительны к направлению, поэтому X до Y могут сосуществовать с Y до X).
+-------+---------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------+---------------------+------+-----+---------+----------------+
| a_id | bigint(20) unsigned | NO | PRI | NULL | |
| b_id | bigint(20) unsigned | NO | PRI | NULL | |
+-------+---------------------+------+-----+---------+----------------+
Типичным запросом будет получение всех связанных объектов (для данного объекта A):
SELECT * FROM objects INNER JOIN relations ON id = b_id WHERE a_id = A
Отношения управляются с помощью простого массива флажков в пользовательском интерфейсе. Чтобы сохранить отношения, я бы вычислил разницу между проверенным / непроверенным в текущем наборе (объекты будут перемещаться по страницам в пользовательском интерфейсе), а затем просто вставить / удалить соответственно;
DELETE FROM relations WHERE a_id = A AND b_id IN(B,C)
# if these relations already exist, will fail silently
INSERT IGNORE INTO relations (a_id, b_id) VALUES (A,D), (A,E)
I может также необходимо запросить обратные отношения, используя просто b_id для выбора - так как он не слева от индекса, будет ли он вообще использоваться? И если нет, будет ли добавление отдельного индекса для него вызывать значительные накладные расходы для записи?