Как обрабатывать просроченные бесплатные аккаунты в среде SaaS

Question

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

Вопрос в том, как наилучшим образом справиться с этой «просроченной» базой данных?

Вы могли бы:

1) сохранить учетную запись в глобальной таблице «user», отметив, что срок ее действия истек

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

2) удалить учетную запись, возможно, переместив ее в таблицу user_history или expired_user

• PRO: ваша пользовательская таблица меньше и содержит только данные «живых» пользователей
• CON: имя пользователя / адрес электронной почты просроченной учетной записи можно использовать повторно (ваши журналы могут быть испорчены, и вы всегда должны регистрировать идентификатор пользователя, отличный от имени пользователя, поскольку он больше не будет уникальным)
• PRO: имя пользователя / адрес электронной почты просроченной учетной записи можно использовать повторно (пользователи с истекшим сроком, которые хотят запустить пробную версию после добавления новых функций, могут сделать это без необходимости выбирать другой адрес электронной почты)
• CON: сбор статистики пользователя становится более сложным

Кто-нибудь сталкивался с такой же проблемой?

Answer 1

Я бы предложил разделить схему на две части:

TABLE: users
user_id (PK)
email_address
password_hash
....

TABLE: user_status
user_status_id (PK)
user_id (FK)
status_date
status_value

Текущий статус данной учетной записи - это учетная запись с самой последней датой статуса. Когда пользователь регистрируется в «бесплатной» учетной записи, вы вставляете запись в user_status со значением состояния «new_free_status»; когда срок действия учетной записи истекает, вы вставляете запись со значением статуса «free_account_expired». Вы используете статус, чтобы проверить, может ли пользователь войти в систему или нет; если вы хотите, чтобы пользователи могли зарегистрироваться как минимум через месяц после истечения срока действия их бесплатной учетной записи, проверьте запись статуса пользователя, чтобы узнать, когда их учетная запись была закрыта.

Конечно, вы можете создать другую справочную таблицу с именем «status» и присоединиться к таблице с «account_type» - таким образом ваши данные станут более самоописуемыми.

Ключевым моментом в этом дизайне является то, что вы хотите отделить профиль пользователя от текущего статуса и отслеживать этот статус с течением времени. Это позволяет вам отвечать на такие вопросы, как «сколько человек подписалось на платную учетную запись после пробной версии?», «Сколько времени между подпиской на бесплатную учетную запись обновляются пользователи?», «Сколько пользователей возвращаются на другую пробную версию? " и т.д.

Answer 2

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

Эта стратегия работает хорошо, конечно, из-за типа приложения. Как правило, вы будете использовать его на ежедневной основе; Вы никогда не будете использовать наше приложение в течение нескольких часов и выбросить его снова. Вот почему это имеет смысл для нас, но для Adobe не имеет смысла делать это, например, с Photoshop.

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