如何在SaaS环境中处理过期的免费帐户

Question

这有点哲学，但是，这里是场景和相关问题。 假设您出售高级帐户，同时提供有时限的免费帐户。 用户使用他们的电子邮件地址注册并登录。创建免费帐户不需要移交任何过于敏感的数据（只是电子邮件）。 免费用户有X天的时间评估您的服务，然后升级到高级帐户或看到他们的免费帐户过期。

问题是：如何最好地处理“过期”数据库？

你可以：

1）将帐户保留在全局“用户”表中，标记为已过期

• PRO：用户名/电子邮件始终是唯一的，无法重新注册 同样的电子邮件
• CON：不能用同一封电子邮件重新注册（也许 在他感兴趣的新功能之后，他想做到这一点 加）
• PRO：所有帐户都在一个地方，更容易处理统计数据 检索
• CON：用户表只能随时间变大

2）删除帐户，可能将其移至user_history或expired_user表

• PRO：您的用户表格较小，仅包含“实时”用户的数据
• CON：过期帐户的用户名/电子邮件可以重复使用（您的日志可能会搞砸，您必须始终记录用户名以外的用户名，因为这不再是唯一的）
• PRO：过期帐户的用户名/电子邮件是可重复使用的（过期的用户希望在添加新功能后再试一次，而不必强制选择其他电子邮件地址）
• CON：用户统计信息收集变得更加复杂

有没有人遇到同样的问题？

Answer 1

拥有一个太大的用户表不应该是一个问题 - 存储是便宜的，如果它的索引很好，你会没事的。我目前正在推出类似的应用程序，我们只是将所有帐户保留在用户表中。如果用户让他们的试用失效超过一个月左右，我们只是让他们再次注册以查看新功能，如果他们需要，我们只需重新激活他们的帐户。

由于应用程序的类型，此策略当然很有效。您通常会每天使用它;你永远不会使用我们的应用程序几个小时，然后再扔掉它。这就是为什么它对我们有意义，但是对于Adobe来说，用Photoshop做这件事是没有意义的。

我所说的可能不适用于您的情况，但我（我只能假设其他开发人员）认为使用多个表将数据分类为类别是一种不好的做法。使用列和WHERE子句来执行此操作，这就是他们的目的。

Answer 2

我建议将架构分成两部分：

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”连接到表格 - 这样，您的数据就会变得更加自我描述。

此设计中的关键是您希望将用户配置文件与当前状态分开，并随时跟踪该状态。这使您可以回答诸如“在试用后有多少人注册付费帐户？”，“注册免费帐户之间多长时间进行人员升级？”，“有多少用户返回进行另一次试用？ “等