Поэтому у меня есть база данных с несколькими таблицами.
Первая таблица содержит идентификатор пользователя, имя и фамилию.
Вторая таблица содержит идентификатор пользователя, процентный идентификатор и процентную оценку.
Существует еще одна таблица, в которой есть все идентификаторы интересов.
Для каждого идентификатора процента (даже если новые добавляются), я должен убедиться, что у каждого пользователя есть запись для этого идентификатора интереса (даже если его пустое или имеет значения по умолчанию).
Помогут ли иностранные ключи в этом сценарии? или мне нужно будет использовать PHP для обновления каждой записи при добавлении нового ключа?
Для каждого идентификатора процента (даже если новые добавляются), я должен убедиться, что у каждого пользователя есть запись для этого идентификатора интереса (даже если его пустое или имеет значения по умолчанию).
Похоже, что в одном из ваших запросов вместо этого требуется OUTER JOIN ( LEFT или RIGHT ).
Например, если вы хотите получить уровень интереса, который имеет конкретный человек для каждого интереса:
Предполагая, что ваши таблицы выглядят так:
пользователей:
user_id PK
пользователь
user_interests:
user_id PK FK
Interest_id PK FK
Уровень заинтересованности
интересы:
Interest_id PK
интерес
SELECT i.interest, ui.interest_level FROM interests i INNER JOIN user_interests ui USING (interest_id) LEFT JOIN users u USING (user_id) WHERE user_id = ?
? является заполнителем.
Обратите внимание, что ui.interest_level будет null для интересов без данных.
Внешние ключи являются своего рода ограничением , поэтому они могут только терпеть неудачу, когда вы пытаетесь добавить записи.
Вы можете выполнить то, что вы описываете, с помощью триггера. Я не знаю синтаксис MySql, но в SQL Server он выглядит примерно так:
CREATE TRIGGER TR_ensure_user_interest ON interest FOR INSERT, UPDATE AS BEGIN INSERT user_interest (user_id, interest_id) SELECT user_id, interest_id FROM inserted ,user EXCEPT (SELECT user_id, interest_id) END
Обратите внимание, что это довольно неэффективный подход, но он должен охватывать многие случаи, о которых вы беспокоитесь.
ОБНОВЛЕНИЕ: Я согласен с другими, которые наблюдали дизайн «запах» здесь. Если вы можете выполнить требуемый результат с помощью запросов JOIN, это будет гораздо более эффективное решение. Тем не менее, я пытался ответить на фактически заданный вопрос. (Кроме того, я был в этой ситуации, когда физические записи полезны для других пользователей базы данных, которые не умеют создавать сложные запросы.)
Похоже, вы заставляете свой физический дизайн слишком сильно отражать ваш логический дизайн.
Возможно, было бы хорошей идеей переосмыслить, почему вам нужно вставлять строку для каждого пользователя в физическую таблицу. Не могли бы вы просто написать свои запросы, чтобы принять значение по умолчанию для invIDID, если для данного пользователя нет связанного интереса?
«Помогут ли иностранные ключи в этом сценарии?»
Нет.
Ваше ограничение является своего рода «полнотой». Это означает, что для каждого нового добавленного интереса должно быть столько строк, добавленных в таблицу USER_INTEREST, как есть пользователи.
Никакая система SQL не может обеспечить это для вас. Это зависит от вас, чтобы обеспечить его соблюдение с помощью кода.