Создать уникальный ключ доступа для настройки учетной записи с помощью SQL

Question

Я пытаюсь найти эффективный способ создания / проверки уникальных ключей доступа для приложения, которое я пишу. У меня проблема из-за того, как настроена база данных SQL.

По сути, есть две таблицы, о которых идет речь. A Users стол и Faculty стол. Между таблицами Users и Faculty существует связь один ко многим. Каждый пользователь будет создавать учетную запись, используя только личную электронную почту и пароль. Это создаст запись в таблице Users.

Теперь я хочу разрешить администраторам вводить домен адрес электронной почты и имя и генерировать ключ установки. После этого пользователь сможет ввести этот ключ доступа, который свяжет его строку в таблице Users со строкой в ​​таблице Faculty с внешним ключом user_id.

Я думал о том, что когда администратор генерирует ключ установки, он создает строку в таблице факультетов с нулевым внешним ключом. Затем пользователь должен будет ввести ключ настройки AND адрес электронной почты domain , введенный администратором. Предполагая, что все совпадает, он добавил бы их user_id в этот столбец внешнего ключа.

Вот где проблемы / вопросы лежат. Было бы более эффективно использовать отдельную таблицу, содержащую установочные ключи и электронные письма, в качестве сортировочной таблицы и выполнять поиск только в таблице с двумя столбцами, прежде чем добавить строку в таблицу faculty? Я думаю, что это может быть быстрее, поскольку строки могут быть удалены после проверки, оставляя меньше строк для поиска каждый раз. Кроме того, я не уверен, есть ли проблема с оставлением внешнего ключа пустым, как в моем первом методе.

Если предположить уникальную пару ключ / электронная почта, будет ли это достаточно безопасно, или мне также понадобятся некоторыеспособ проверки против вошедшего в систему пользователя?

Любые ресурсы или идеи с благодарностью.

Answer 1

Я сомневаюсь, что если вы создадите отдельную таблицу для этой цели, вы получите большую выгоду в производительности, но это существенно улучшит целостность данных. Создание новой записи факультета для каждого разрешенного доступа может привести к избыточности, поскольку вам придется добавлять один и тот же факультет в несколько записей, что в долгосрочной перспективе приведет к возникновению больших проблем, поскольку будет все труднее справляться со всеми избыточностями, что в конечном итоге приведет к несоответствиям,Таким образом, первоначальный подход нарушил бы концепцию нормализации базы данных . Вы получите намного лучшие результаты, если у вас есть таблица для пользователей, таблица для факультетов и другая таблица для users_of_faculty. Это позволит пользователям иметь доступ к большему количеству факультетов, если это необходимо, и каждый пользователь, каждый факультет будет создаваться в одном месте, их отношение будет изменяться чаще, когда доступ предоставляется, изменяется или отзывается для некоторых пользователей на некоторых факультетах.