Как бы вы спроектировали эту БД?

Question

Мы запускаем веб-сайт (платная подписка), и процесс регистрации включает в себя ввод кода активации. Коды активации напечатаны на скретч-картах и ​​продаются через офлайн каналы. Некоторые из этих карт рассчитаны на 1 месяц. Другие на 3 месяца и 1 год. Коды активации представляют собой уникальные 10-значные случайные числа.

Когда доступ истекает, пользователи могут купить другую карту активации и продлить подписку, введя новый код активации. Кроме того, мы также сможем продлить подписку, если они об этом попросят. Например, до определенной даты (например, 1 дополнительная неделя).

Учитывая вышеизложенную информацию, как бы вы спроектировали БД для отношения user-Activation_code? Как вы думаете, этот дизайн хорош?

tbl_user
----------------
id
name
status_id

tbl_user_status
----------------
id
description

tbl_activation_code
----------------
activation_code
activation_code_type_id
activation_code_status_id
user_id
activated_date
expiry_date

tbl_activation_code_type
----------------
id
description

tbl_activation_code_status
----------------
id
description

Обновление : потребуются только коды активации:

1) При первоначальной регистрации

2) Ближе к дате окончания доступа (скажем, 7 дней), когда система отображает уведомление со ссылкой на страницу для ввода кода активации

3) После истечения срока действия, когда пользователь пытается войти, ему будет предложено ввести код активации

Следовательно, пользователь не должен вводить код активации, как и когда хотел.

Answer 1

Это не плохо. Тем не менее, я бы предложил добавить два поля в tbl_user:

tbl_user
----------------
id
name
status_id
activated_date
expiry_date

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

• Карта 1 - с 1 сентября по 30 сентября
• Карта 2 - с 16 сентября по 15 октября

Там есть пятнадцать дней перекрытия, так что activated_date пользователя должно быть 1 сентября , а expiry_date должно быть 30 октября (15 октября + 15 дней) .

Учитывая это, я бы изменил tbl_activation_code, так как expiry_date немного вводит в заблуждение. Вместо этого создайте столбец с именем access_days, который будет использоваться для расчета expiry_date.

пользователя.

Кроме того, если вы хотите запомнить выпущенные карты, даже если они не активированы, я бы разбил tbl_activation_code на две таблицы:

tbl_activation_code
----------------
activation_code
activation_code_type_id
activation_code_status_id
access_days

tbl_activation
----------------
activation_code_id
user_id
activated_date

Answer 2

Я бы подумал немного о денормализации - в данный момент, чтобы определить, имеет ли пользователь текущий доступ или нет, вам нужно просмотреть потенциально несколько записей для этого пользователя в tbl_activation_code, чтобы увидеть, существует ли активная запись для этого пользователя.

Так что, возможно, стоит добавить суррогатное поле IDENTITY / autonumber в tbl_activation_code и добавить внешний ключ к этому в tbl_user - это будет указывать на текущую запись кода активации пользователя, упрощая сценарии, в которых вам нужно найти текущее состояние доступа пользователя. Таким образом, запись пользователя всегда будет напрямую ссылаться на текущий код активации, плюс у вас будет полная история предыдущих кодов.