ВСТАВКА в таблицу MySQL для отношений пользователя - PullRequest
Новая
       7

ВСТАВКА в таблицу MySQL для отношений пользователя

0 голосов
/ 12 ноября 2011

У меня есть таблица для отношения многих ко многим пользователям (три столбца: отношение_пользователя, идентификатор_пользователя, идентификатор_пользователя). Как я могу сохранить отношения уникальными, когда таблица принимает любую запись? Когда у меня есть ряд 22 11 43 Как я могу предотвратить INSERT для next_id 11 43 и, что более важно, next_id 43 11? Когда пользователь 11 запрашивает отношения с пользователем 43, пользователь 43 не должен иметь возможность запрашивать отношения с пользователем 11.

Как проверить два столбца перед вставкой?

И моя проблема еще более серьезна, так как у меня есть две таблицы (запрос и отношения). Строка из таблицы запросов будет удалена и вставлена ​​в отношения после одобрения пользователем. Причиной использования двух таблиц является то, что многие ожидающие запросы делают таблицу такой длинной, которую следует регулярно использовать для отображения друзей пользователя.

При вставке запроса от пользователя 11 к пользователю 43, какой самый быстрый и эффективный способ проверить наличие в таблицах строк 11 43 и 43 11: запросы и взаимосвязи?

Ответы [ 2 ]

2 голосов
/ 12 ноября 2011

Каждый раз, когда я использовал «Связывающую таблицу» , чтобы отслеживать многие отношения ко многим, я всегда УДАЛЯЮ любые существующие отношения до ВСТАВЛЕНИЕ новые отношения. Однако в вашем случае это может не сработать, потому что ваша таблица ссылок содержит суррогатный ключ отношение__. Если вы удалите суррогатный ключ из таблицы ссылок и воспользуетесь хранимой процедурой, вы сможете выполнить все, что вы перечислили.

Идентификация дубликатов

Создание Просмотр с использованием логики CASE CREATE VIEW vFriendRequests AS SELECT CASE WHEN ID_1 < ID_2 THEN ID_1 ELSE ID_2 END CASE as RequestId_1, CASE WHEN ID_1 < ID_2 THEN ID_2 ELSE ID_1 END CASE as RequestId_2 FROM Friend_Requests_Table Затем вы можете сделать выборку отдельно от этого представления, чтобы получить только уникальные наборы запросов.
1 голос
/ 12 ноября 2011

Вот несколько вариантов достижения желаемого (выбор или объединение зависит в основном от вашей модели данных, архитектуры клиента и механизма хранения):

  • создать уникальный композит index в обоих user_id столбцах

  • отозвать INSERT в relationships и реализовать хранимую процедуру для INSERT (это можетделать любые проверки и т. д., которые вы хотите) ИЛИ внедрить ВКЛ перед вставкой триггера , который делает то, что вы хотите

  • ЕСЛИ порядок user_id s не соответствуетизмените код INSERT, чтобы всегда сортировать оба ID с до INSERT (например, с помощью подхода хранимой процедуры)Таким образом, вам не нужно явно проверять, но индекс будет делать всю работу за вас

  • создайте четвертый столбец idcomb в relationships с UNIQUE INDEX и ON BEFORE INSERT TRIGGER, который просто берет оба user_id, сортирует их и объединяет их с промежуточным значением - и присваивает это значение столбцу idcomb в качестве значения ... таким образом вся работа выполняется с помощью индекса, и никаких изменений на стороне клиентатребуется (когда вставлен какой-то дубликат, просто возвращается с ошибкой)

...