0

我有我的用户表，其中有 user_id。因此，所有用户内容、日志、详细信息表等都将 user_id 作为父用户表的 FK。这是一个社交网站。因此，当用户注册时，他们会被分配一个随机的 user_id。显然，ID 一旦分配就永远不会改变，所以：

1）我假设我不需要在任何 FK 引用上使用“ON UPDATE CASCADE”，因为 user_id 无论如何都不会改变？

2) 在任何用例中，我是否需要在任何地方为 user_ID FK 设置任何“ON DELETE”或“SET NULL”？

3) 如果会员大部分都删除了他的帐户，我将设置一个删除标志。但是我正在为用户提供增强的隐私，以便他们从数据库中删除他们的整个记录​​，就像他们从未存在过一样，所以我有两种情况：

A) 仅删除所有用户的足迹（硬删除），但保留内容。因此，如果用户发布了照片，我要删除的只是 A 先生拥有照片 ID 33445，但我将照片保留为孤儿。（在硬删除的情况下，A 先生也将从用户表中删除）。因此，现在大约有 16 个引用用户足迹的表需要设置为 NULL 或默认 user_Id 为 999，我指的是不存在的用户。

B）删除所有的指纹和所有的内容。所以所有内容（userID 和 object_iD）都设置为 NULL 或 999。如果我正在执行硬删除，那么我需要从我的文件系统中物理删除照片。

我什至不确定这一切是从约束、触发器还是在应用程序端处理的？目标是让它尽可能简单和快速，而且开销很小。

平台：MySQL、codeIgnitorPHP、专用托管环境。

4

2 回答 2

0

  1. 正确：如果不允许更改 User_ID，则 ON UPDATE CASCADE 无关紧要。这很好。

  2. 这是您的判断。我会说“不”，使用 RESTRICT 是一个很好的默认值。但是，如果您想在删除 User_ID 时删除数据，那么 ON DELETE CASCADE 可能有意义 - 但可能没有。ON DELETE SET NULL 不合适。

  3. 问题分为两部分 - 同样回答。

    (A) 删除材料为好；对我来说，不删除你表示你会做的所有材料似乎并不好。该材料不太可能是完全匿名的（无法识别）——有些会是，有些会包含允许识别它的参考资料。所以，你应该（当然是IMNSHO）完全删除——所以我推荐下面的选项（B）。如果您不能或不愿意，那么将数据与通用的“已删除用户 ID”重新关联是比较好的 - 至少，一旦删除了几十个用户，就会有足够多的垃圾给用户带来混乱内容。当然，您还需要做更多的事情来匿名数据；您需要删除或重置时间戳等。孤立数据将无法访问；它应该被删除。

    (B) 这是更好的选择 - 删除所有内容意味着删除所有内容。当然，您可能需要担心数据库的档案；信息可以从他们那里恢复。这可能会受益于 ON DELETE CASCADE 规则。您可能会通过将 User_ID 标记为已删除（“软删除”）来进行初始删除。经过一段有限的时间（我猜是 24 小时到 7 天），您将进行硬性物理删除。到那时，用户的数据将被正式删除，可能通过级联删除规则自动删除，可能通过表的“手动清理”（即，采用 User_ID 并四处删除其存在的所有证据的自动化过程）任何东西的所有者）。但是请注意，其他人可能仍然拥有 x-refs 现在不存在的用户的内容；删除整个记录实际上是极其困难的。

于 2011-01-23T01:12:41.303 回答
0

对于删除所有子用户信息的真正“硬删除”，您可以在外键上使用 ON DELETE CASCADE，或者您可以在删除父记录之前简单地从子表中删除。

对于“半硬删除”，您可以删除用户记录但保留辅助信息（我从未遇到过的设计，顺便说一句），您可以使用 ON DELETE SET NULL。然而，允许在外键列中使用 NULL 的想法让我感到不安（你怎么能确定这是一个已删除的记录，而不是来自现有用户的“丢失”记录？）所以如果你需要保留周围的孤立信息，我希望有一个特殊的用户记录来包含这些信息，正如你所建议的。

于 2011-01-23T01:28:36.637 回答