Должен ли я создать отдельную таблицу пользователей для разных веб-продуктов на одной платформе?

У нас есть веб-продукт для молодого профессионала, который дает им возможность создать свою страницу, чтобы показать свою профессиональную идентичность. Таким образом, таблица users , которая имеет как информацию о пользователе (адрес электронной почты, пароль, имя), включая их учетные данные и информацию о своей странице (премиум или нет, адрес страницы, тема)

Теперь мы хотим предложить рекрутерам зарегистрироваться на нашей платформе для просмотра кандидатов. Рекрутер также может быть пользователем со страницей, но не обязан.

Теперь наши два подхода:

A/Создать таблицу recruiters с именем и учетными данными рекрутера и столбцом user_id для подключения к ID для пользователей таблицы , если они создали сайт.

  • Преимущества: продукт может быть легко разработан отдельно, двумя разными командами.
  • Неудобно: дубликаты имени и учетных данных, если рекрутер также является пользователем. Нам нужно будет либо обновить оба учетных данных, если они будут обновлены, либо дать им две разные комбинации электронной почты/пароля, одну для учетной записи пользователя, одну для своей учетной записи рекрутера.

Структура базы данных:

users
ID name email password group_id premium theme page_address

recruiters
ID name email password company_id user_id

B/Добавьте рекрутеров в таблицу users с помощью другого group_id и переместите всю информацию о странице пользователей в другую таблицу (премиум или нет, адрес страницы, тема). У нас также будет третья таблица для рекрутера, содержащего любую информацию, относящуюся к ним.

  • Преимущества: одна таблица со всеми учетными данными.
  • Неудобно: если мы достигнем миллионов пользователей, любой запрос среди рекрутеров должен будет взять крошечное подмножество среди огромной таблицы. Кроме того: много соединений, чтобы получить информацию о сайте для каждого пользователя.

Структура базы данных:

users
ID name email password group_id

pages
user_id premium theme page_address

recruiters
user_id company_id

C/Любое другое решение?

Спасибо за ваши данные!

Тристан

4
nl ja de
Вариант B мне кажется прекрасным. Даже если вы получаете миллионы пользователей, ваша база данных должна обрабатывать это с правильными индексами. Вы все равно должны получать время запроса 1-2 мс. Если по какой-то причине это стало проблемой, вы можете переместить неактивных/удаленных пользователей в историческую таблицу, чтобы таблица не была доступна только для активных пользователей. Вы можете создать представление для создания общих объединений для вас, что упростит запросы.
добавлено автор ryan1234, источник
Мышление о шраме теперь может быть немного досрочным. Если ваш сайт растет до такой степени, что у вас 10-миллионное количество пользователей, ошпаривание может и не быть вашей самой большой проблемой. На данный момент я бы подумал, что это предварительная оптимизация. Но если вы доберетесь туда, вы правы, это может быть большой проблемой для поддержки баз данных на серверах. Вы всегда можете проверить что-то вроде Монго, у которого есть встроенный штор.
добавлено автор ryan1234, источник
Спасибо за ваш комментарий, как насчет базы данных? Если мы разделим базы данных, которые станут проблемой.
добавлено автор Tristan, источник

1 ответы

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

Большой подход к решению таких проблем заключается в установлении концептуальных отношений между объектами. Например :

  • Users are or aren't Recruiters would be a 0..1 <-> 1 relationship or an optional One to One
  • Pages belongs to a Users would be a 1 <-> 1 relationship or One to One
  • Recruiters might have a Pages would be a 0..1 <-> 1 relationship or an optional One to One

Это упражнение поможет вам понять, как перечислить ваши сущности и организовать внешние внешние ключи . Это хороший первый шаг, который в вашей ситуации дает нам три таблицы: Users , Recruiters и Pages . Обратите внимание, как внешние ключи для от одного до одного были помещены в обязательный 1 мощность таблицы.

enter image description here

Теперь, чтобы определить, где разместить столбцы данных, и должны ли вы иметь новые таблицы: простой трюк заключается в том, чтобы написать все ваши denormalized будет иметь как таковое, ориентируясь на наиболее образованный объект, который у вас есть.

enter image description here

Этот пример довольно очевиден, но я все еще думаю, что он отвечает на ваш вопрос и ваши сомнения относительно дублирования группы и столбцов.

enter image description here

На этом этапе я понял, что забыл включить объект Companies , который будет указан как таковой:

  • Companies can have multiple Recruiters would be a 1..* <-> 1 relationship or a One to Many

enter image description here

Еще раз помните, что люди могут не всегда соглашаться с этим подходом, но с учетом этого небольшого контекста; это был простой ход мыслей. Ответ, который вы бы искали: Дублирование смысла столбца - это подсказка, что вы должны по-разному подойти к своей схеме данных. Вот скрипка .

Если у вас есть какие-либо вопросы или вы чувствуете, что это неправильно, не стесняйтесь комментировать!

4
добавлено
Благодарим вас за подробный ответ. Фактически мы пошли на подход A в конце концов, главная причина в том, что они представляют собой два разных продукта, поэтому мы рассматриваем сейчас «Пользователи» как «Кандидаты» и располагаем отдельной таблицей для рекрутеров. Со временем мы увидим, был ли это правильный выбор!
добавлено автор Tristan, источник
dbGeeks
dbGeeks
545 участник(ов)

Чат про базы данных, их устройство и приемы работы с ними. Разрешаются любые адеватные дискуссии в рамках тематики чата.

Разработка СУБД
Разработка СУБД
143 участник(ов)