#mysql #database-design
#mysql #база данных-дизайн
Вопрос:
Я пытаюсь найти способ отслеживать присутствие (и отсутствие) уроков студентов. Основная проблема заключается в том, что они заранее оплачивают серию из 10 или 30 уроков, и как только это будет сделано, они могут оплатить новую серию.
Каково наилучшее решение для этого?
У меня будет две таблицы, которые выглядят примерно так
присутствие
идентификатор
user_id
lesson_id
отсутствие
идентификатор
user_id
lesson_id
причина
Я думал добавить в обе таблицы логический столбец, который будет иметь значение true, когда серия будет завершена (своего рода закладка). Затем, когда я обращаюсь к базе данных, мой запрос для каждого идентификатора пользователя подсчитывает, сколько записей существует после последнего истинного значения (если таковое имеется).
Для меня это не звучит как хорошая стратегия, но я не могу найти другого способа.
Комментарии:
1. У меня была бы только 1 таблица (посещаемость), так что, если причина отсутствия в большинстве случаев избыточна — если вы действительно беспокоитесь о пространстве, есть код отсутствия и другая таблица для хранения значения этого кода. Я понятия не имею, что такое серия в этом контексте, но если уроки принадлежат серии, то может подойти другая таблица (таблицы), содержащая связь серии с уроком.
2. спасибо за ваш вклад! Под серией я подразумеваю, что каждый студент платит за 10 или 30 уроков, и как только у него больше не останется уроков, он может подписаться еще на 10 или 30. (Мои извинения за путаницу). Поэтому я должен отслеживать только недавно оплаченные уроки
Ответ №1:
Во-первых, вам нужна таблица User_Lesson_Series:
User_Lesson_Series
- ID
- идентификатор пользователя
- number_of_lessons_paid_for
- payment_date
- количество сохраняемых уроков
Во-вторых, предложение П.Сэлмона о наличии таблицы посещаемости (а не таблицы присутствия и таблицы отсутствия) является хорошим:
Посещаемость
- ID
- lesson_id
- user_lesson_series_id
- отсутствие_флаг
- отсутствие_причина
При вставке записи в User_Lesson_Series в первый раз, установите для number_of_lessons_remaining то же значение, что и для number_of_lessons_paid_for.
Каждый раз, когда вы записываете посещаемость (или неявку) учащегося в таблицу посещаемости, вы также должны обновлять родительскую строку этой записи в таблице User_Lesson_Series, уменьшая number_of_lessons_remaining на 1.
Если запись User_Lesson_Series имеет number_of_lessons_remaining = 0, то вы не должны разрешать больше записывать записи о посещаемости для этого идентификатора user_lesson_series_id. Вместо этого вам следует потребовать оплаты новой серии пользовательских уроков, что потребует создания новой записи User_Lesson_Series.
Последующие записи о посещаемости будут иметь идентификатор user_lesson_series_id этого нового User_Lesson_Series.
Комментарии:
1. Спасибо! Пара вопросов: при добавлении «number_of_lessons_remaining» мы не дублируем данные? (потому что это может быть экстраполировано с остальными данными). Кроме того, будет ли хорошей идеей иметь запрос, который может перепроверять счетчик number_of_lessons_remaining? И, наконец, absence_flag предназначен как значение bool?
2. Привет, патч, да, вы могли бы избавиться от number_of_lessons_remaining, если вы уверены, что всегда можете получить его из посещаемости, но это зависит от требований (возможно, студентам иногда предоставляется дополнительный бонусный урок, за который им не нужно платить, что означает, что приложение должно увеличивать number_of_lessons_remaining …) И absence_flag будет логическим значением или да / нет, это верно.
3. Спасибо, Набав! таким образом, я могу заменить number_of_lessons_remaining на expired_flag, что это верно, когда больше не осталось уроков, верно? Я изначально разделил присутствие / отсутствие, потому что не все отсутствия будут вызывать подсчет уроков (зависит от кода причины). Я могу сделать это в одной таблице и иметь дополнительную фильтрацию, но хорошая ли это идея?
4. У вас все равно должна быть посещаемость в виде единой таблицы; однако, если не все отсутствия уменьшат количество оставшихся уроков, я бы настоятельно рекомендовал иметь атрибут number_of_lessons_remaining в User_Lesson_Series. После записи записи посещаемости приложение должно (в зависимости от определенных значений в записи посещаемости, которую оно записывает) либо уменьшить number_of_lessons_remaining, либо оставить number_of_lessons_remaining в покое.
Ответ №2:
Я бы, вероятно, создал эту таблицу student_lesson:
student_lesson (student_id, lesson_id, status_id, absence_reason)
плюс таблица состояния для статусов Открыто, посещено, отсутствует.
Как только студент платит за следующие n уроков, вы создаете n строк в таблице student_lesson. И когда урок пройден, вы обновляете статус либо на посещенный, либо на отсутствующий.
С индексом student_id и status_id вы можете быстро увидеть, сколько открытых уроков у студента еще есть.
Комментарии:
1. Спасибо за идею! Никогда не думал об «открытии слотов» в таблице! В моем случае я не думаю, что это сработает, поскольку у меня могут быть некоторые пропуски, которые не учитываются как урок, и может случиться так, что учителю придется записывать присутствие, даже если уроков не осталось