Дизайн базы данных: несколько пользовательских объектов. Один или несколько таблиц

Question

Я создаю приложение PHP, которое имеет 3 основных типа сущностей: Coach, Student, Lesson, где тренеры создают цифровые уроки для студентов. Я использую MySQL и таблицы innoDB.

Требования

1. Тренер и ученик входа в систему.
2. Тренер может предоставить цифровой урок специально для одного студента.

Я не уверен, какая лучшая схема БД использовать с учетом требований. Здесь два варианта:

Вариант 1
пользователя (PK ID, user_type (тренер или студент), Firstname, фамилия, адрес электронной почты, пароль и т.д. ...)
Урок (PK идентификатор, FK coach_user_id (ссылка: User.id), FK student_user_id (ссылка: User.id), lesson_name, и т.д ...)

Pros:
- одна пользовательская таблица
- Каждый пользователь имеет уникальный идентификатор и адрес электронной почты
- упрощает вход в систему с помощью одной таблицы

Минусы:
- Нет проверка user_type когда тренер или студент User.id записывается как FK в таблице урока. Эта проблема будет повторяться в любой новой таблице, где тренер или ученик User.id должен быть записан как FK.
- Потенциальные проблемы полиморфизма и необходимость нормализации вниз по дорожке.

Вариант 2
Тренер (PK ID, Имя, фамилия, адрес электронной почты, пароль и т.д. ...)
Student (PK ID, Имя, фамилия, адрес электронной почты, пароль и т.д. ...)
Урок (PK идентификатор, FK coach_id (ссылка: Coach.id), FK student_id (ссылка: Student.id), lesson_name, lesson_text, и т.д ...)

Pros:
- Нормированный DB схемы. Независимый тренер, таблицы учеников.
- Нет вопросов проверки типа пользователя. Идентификатор тренера и идентификатор ученика FK указывают независимо на Coach.id и Student.id соответственно.

Минусы:
- тренер и ученик может иметь тот же идентификатор. (Это можно решить, хотя с префиксами ID, например, C1001, S1001)
- У тренера и ученика может быть такое же электронное письмо.
- Login auth включает в себя запрос двух двух таблиц для одной страницы входа в систему или создания 2 разных страниц входа и типов запросов авторизации.

Я действительно разорван, что является лучшим способом. Есть лучший способ сделать это?

Answer 1

На мой взгляд, оба ваших подхода будут работать. Первый из них более универсален и способен подгонять различные в настоящее время неизвестные требования. Если вы его выберете, я бы рекомендовал добавить концепцию роли в модель. «User_type» - это роль, и один пользователь может быть связан с разными ролями [в то же время]. Кроме того, «Книга ресурсов модели данных» Лен Сильверстона - отличный ресурс.

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

1) Плюсы:

• легко приспособить новые функции без существенных изменений в схеме
• очень гибкий
• легко построить кубов на вершине схемы
• подходит долгосрочные проекты

минусы:

• требует больше ресурсов (опытный DBA/специалист модели данных [с], сравнительно больше времени дизайн)
• путь более сложный, чем (2)

2) Плюсы:

• быстрой поставка первой рабочей версии
• довольно легко понять даже нетехническими людьми (пока не вырастет)
• подходит для небольших проектов или проекты с четко определенными областями, которые [почти] никогда не изменится

Минусы:

• Бесконечный рефакторинг схемы, как новые требования предъявляются к
• если проект живет достаточно долго, база данных становится полным " больше не используется»столбцы (или другие объекты БД) никто не хочет трогать
• труднее для обеспечения целостности

Я надеюсь, что м akes смысл и поможет вам принять правильное решение, которое соответствует вашим потребностям.

Answer 2

Вариант 1 выглядит лучше для меня.

Это упростит ваш код, если вы не хотите отличать учеников от тренеров и будете почти такими же, как вариант 2, если вы хотите их отличить.

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

Я не уверен, что вы подразумеваете под «Потенциальные проблемы полиморфизма и необходимость нормализации по дорожке»..