何时使用关系数据库结构？

Question

我正在创建文件托管服务，但是现在我正在创建注册的帐户电子邮件激活部分。 因此，我不得不提出一个数据库结构。

现在是：

users
  id
  first_name
  last_name
  email
  password
  since
  active
  hash_activate

但是我也可以像关系数据库一样来做：

users
  id
  first_name
  last_name
  email
  password
  since

activation
  id
  user_id
  hash
  active

最好的方法是什么？ 又为什么呢？

Answer 1

仅当一个用户可以进行多次激活时，第二个才有意义。 您不会说这是对还是错，所以我无法建议您。

Answer 2

如果每个人一次只有一个激活哈希，则可以将其与用户存储在同一表中。

但是，将其分开的一个优点是用户仅在短时间内拥有一个激活哈希，因此，为了使用户记录更小，可以将哈希存储在单独的表中。 保持用户记录较小，使其性能更高。 在这种情况下，您将没有active列。 您只需删除不活动的哈希即可。

如果确实将激活列存储在用户表中，只需确保按名称选择列即可。 例如，在大多数情况下，您需要这样做：

SELECT id, first_name, last_name, email, password
FROM users

代替：

SELECT *
FROM users

您只需要在需要时选择激活列。

Answer 3

如果激活是暂时的，或者散列将某人定义为激活，则使其与众不同。 否则，那真的没关系。

但是，在没有更多信息的情况下，两者之间的关系不一定或多或少。 如果对每行中的值组合施加唯一约束，并使用NOT NULL约束设置每一列，则第一个约束将是非常相关的。

当数据的正确性随着时间的推移与应用程序对数据的处理同样重要（如果不是更重要）时，和/或当数据结构的正确性/一致性对于应用程序的正确操作至关重要时，您可以使用关系设计。但不一定由应用程序自己的操作来保证。