我们是否应该删除数据库中的数据？

我是数据库新手，正在尝试了解基本概念。我已经学会了如何删除数据库中的数据。但是我的一个朋友告诉我，永远不要删除数据库中的数据。相反，当不再需要它时，最好将其标记或标记为“未使用”。

真的吗？如果是这样，那么像IBM这样的大公司将如何处理其一百年或更长时间的数据？

与所有这些事情一样，答案是“取决于”。

如果用户有可能想要返回数据，那么您的朋友是对的-您并没有真正删除，只需将记录标记为“已删除”即可。这样，当用户改变主意时，您可以恢复数据。

但是，如果删除的数据已存在一定时间（例如一年），则可以决定从活动表中真正删除它，但如果用户愿意，可以将其保存在存档表中，甚至只是备份回来了。这样，您可以将数据量（活动的和最近删除的）保持在最低水平。

但是，如果数据是临时数据或易于重新创建，则您可以决定实际删除数据。

您必须删除一类数据-这是用户不希望您再保留的个人数据。可能存在一些地方法律（例如欧盟）将其作为强制性要求（感谢Gavin）

同样，可能存在一些规则要求您不要删除数据，因此在决定与任何监管机构进行任何检查之前，必须采取哪些措施来遵守法律。

对于许多公司而言，这实际上是一个重大问题。无法完全确定实际使用的数据，因此它只能位于数据库中。数据删除和归档需要成为每个大型系统设计的一部分，但很少如此。大多数公司只是忍受它，购买更大的磁盘并调整其查询和索引以保持性能，直到他们更改系统，然后他们花费了大量的精力来识别当前数据，然后仅将这些记录迁移到他们的新系统中。

是的，您应该从数据库中删除数据，但是要知道何时何地通常并不容易。

对此已经有很多好的答案，可以归结为“取决于情况”，而我对此无能为力。

但是，我认为需要提及的一件事是，您永远都不要重复使用由序列或AUTO_INCREMENT系统生成的主键。

当您删除由这样的系统分配了主键的项目时，主键列中会留有空白，由已删除的数据留下。有很大的诱惑要在添加新项目时将这些间隙重新分配给新项目，甚至更糟的是，将现有数据改组为新ID以消除这些间隙，但是这样做会引起您遇到的问题如果您只剩下钥匙，就无需处理。

假设您要保留用于管理重新订购耗材的打印机数据库。打印机13，一台旧的激光打印机，由于无法经济维修而损坏，因此将其丢弃。同时，由于不相关的原因，有人订购了新的热敏打印机以在仓库中进行条形码打印，并且该打印机恰好在替换打印机13之前就到达了。管理员将该新打印机登录到数据库中，因为13现在是免费的并且您正在回收ID，新的热敏打印机将获得13作为ID。

现在有人告诉您打印机13的墨水即将用完。您还记得打印机13是激光打印机，因此您不必费心在数据库中查找它，而下订单订购碳粉盒。因为打印机13不再是激光打印机，所以实际上只需要订购热敏墨水包。当墨粉盒到达时，您将无法使用它，因为它是打印机的错误墨水补充，您无法再打印出任何条形码，也无法运送任何等待发运的订单。

更糟糕的是，如果删除打印机13并对其进行洗净以填补空白，那么接下来将发生什么情况呢？打印机14（一些旧的点矩阵）变成打印机13，打印机15变成打印机14，依此类推。

所有打印机上都有标签，因此可以与数据库进行交叉引用，但是现在所有标签都已过期。您必须四处走走，找到业务中的每台打印机（可能会成百上千个！），然后重新标记它们。这几乎不是时间的有效利用。而且这也是一个容易出错的过程，如果永不完成，会发生什么？有人打来电话，说打印机14发生故障，需要紧急修复，因此您在查找它时发现打印机14是Reception中的喷墨打印机。仅仅是因为您洗了周围的ID，实际上是点矩阵打印机需要紧急修复。打电话给那个问题的那个人挂了电话，而接待员有一个技术支持人，她从来没有叫过他来修理没有损坏的打印机。

您应该将自动递增系统分配的ID视为永久性的，它们是不可变的，即使ID所指的东西已经不复存在，也无法重用。有些人声称他们不想担心ID会用完，但是即使使用32位系统和已签名的ID，仍然有大约20亿个ID可用。如果您可以将ID列设置为无符号，则这将增加一倍，达到40亿，并且在64位系统上，可用ID的数量实际上大于天空中的星星数量。您不会用完ID。

这里已经有很多好的答案。我只想补充一种没有人提及的情况：

敏感数据。如果用户删除了它，那么您最好实际删除它！

想到的一种非常常见的情况是更改/重置密码。您不希望在数据库中存储旧密码（即使它们被散列，加盐等）。用户可能在其他站点上使用了旧的（和错误的）密码。

同样，当涉及到允许您存储某些类型的数据多长时间的法律时，软删除当然也不会做。您必须实际删除它。

因此，我想问自己：如果我让用户（或其他人，例如政府）相信数据已被删除，会发疯吗，但实际上我仍然知道并可以随时还原它？

我通常不删除数据库中的用户数据。我将它们标记为隐藏。用户经常会意外删除某些内容，并需要轻松地对其进行替换。它还有助于保持相关数据的参照完整性。这适用于中小型数据库。在性能受此决定严重影响的系统中，将以特殊方式处理该系统，例如存档表，自动备份等。

我们会根据需要丢弃后端数据，例如过期的网站会话数据和旧日志信息。永远保留它们毫无意义。

像往常一样，确切的答案实际上取决于具体情况。

几年来，我一直在研究外汇申请。多年来，应用程序收集的数据对性能有影响（例如指数）。

完成代码方面的工作后，我们向管理层提出了将一年以上的数据存档的建议。他们验证了这个概念（法律问题），幸运的是我们能够做到这一点。因此，我们删除了数据，但同时也将其存档，以便企业仍可以运行其报告等。

在大多数情况下，您应该保留数据，以防将来需要时使用。您工作的公司可能希望查看历史数据以做出决定，从而将公司推向某个特定方向。

您应该在每个表中添加“ Date_Time_Removed”列，然后代替实际删除行，而是设置虚拟删除该行的日期和时间。然后在您的存储过程或sql中，将考虑“ Date_Time_Removed”列，例如，从table1中选择等等，其中date_time_removed为null

当然，意外删除的行应永久删除，尤其是测试数据。

通过保留所有合法数据，您还必须选择将来使用数据库进行仓储。

与其他情况相比，另一种情况是删除数据，但是在数据库中执行的操作日志（包括删除操作）会长时间存储在归档中。此方法的主要范围是实现到过去日期的回滚系统，但是它也可以用于以某种方式存储已删除的数据（已从数据库中删除，但存储在归档中）。

存储已删除数据的档案并不是一件大事。大公司可能还会存储代码的版本和更多信息（更不用说与技术无关的东西了），因此最终存储大数据对于他们来说是很常见的事情。