我的用户表有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）删除所有的foorprints和所有内容。所以一切（userID和object_iD）都设置为NULL或999.如果我正在进行硬删除，那么我需要从文件系统中删除照片。
我甚至不确定这些是从约束，触发器还是在应用程序端处理的？目标是尽可能简单快捷地开发它。
平台：MySQL，codeIgnitorPHP，专用托管环境。
答案 0 :(得分：0)
正确：如果不允许更改User_ID，则ON UPDATE CASCADE无关紧要。这很好。
这是您的判断。我会说“不”，使用RESTRICT是一个很好的默认值。但是，如果要在删除User_ID时删除数据，则ON DELETE CASCADE可能有意义 - 但可能没有。 ON DELETE SET NULL不合适。
问题分两部分 - 同样回答。
（A）删除材料是好的;我不会删除你表示你会做的所有材料似乎不太好。这些材料可能不是完全匿名的（无法识别） - 有些将是，有些将包含允许识别它的参考。所以，你应该（IMNSHO，当然）完全删除 - 所以我建议下面的选项（B）。如果您不能或不会，那么将数据与通用的“已删除的用户ID”重新关联是适度的 - 至少，一旦删除了几十个用户，就会有足够的垃圾来解决这个问题。内容。当然，您需要做的不仅仅是匿名化数据;您需要删除或重置时间戳等。无法访问孤儿数据;它应该删除。
（B）这是更好的选择 - 删除所有内容意味着删除所有内容。当然，您可能需要担心数据库的存档;这些信息可以从他们那里获得。这可能会受益于ON DELETE CASCADE规则。您可能通过将User_ID标记为已删除（“软删除”）来执行初始删除。经过一段有限的时间（24小时到7天，我猜），你会做一些艰难的物理删除。此时，用户的数据将被正式删除，可能通过级联删除规则自动删除，可能通过“手动清理”表（即，采用User_ID的自动过程，并删除其存在的所有证据，任何东西的所有者）。但请注意，其他人可能仍然拥有x-refs现在不存在的用户的内容;实际上很难清除整个记录。
答案 1 :(得分：0)
对于删除所有辅助用户信息的真正“硬删除”，您可以在外键上使用ON DELETE CASCADE，或者只需在删除父记录之前从子表中删除。
对于“半硬删除”，您删除用户记录但保留辅助信息（我从未遇到的设计，顺便说一句），您可以使用ON DELETE SET NULL。但是，在外键列中允许NULL的想法给了我一些想法（你怎么能确定它是一个已删除的记录而不是现有用户的“丢失”记录？）所以如果你需要保留孤立的信息，我会很好地包含这些信息的特殊用户记录，如你所建议的那样。