最近，我发现自己陷入了数据库混乱，管理层希望能够从数据库中删除数据，但仍希望该数据出现在其他地方。示例：他们想要删除产品 whizbang 的所有实例，但他们仍然希望 whizbang 出现在销售报告中。（如果他们在前一个日期运行了一个）。
现在我可以添加一个字段，比如 is_deleted，它将跟踪该产品是否已被删除，因此仍然保留我的所有引用，但在一段时间内，我有可能容纳大量死数据。（永远不会再次访问的数据）。如何处理这不是我的问题。
我很想知道，根据您的经验，数据的平均寿命是多少？也就是说，在被替换或删除之前，数据的平均存活时间或有效时间是多少？我知道这与您所存储的数据类型有关，但肯定所有数据都有某种寿命？
数据永远存在……或者通常它应该存在。一种常见的做法是为记录设置结束和/或开始日期。因此，对于您的 whizbang，您有一个开始日期（这样它就不会在正式发布之前出现在销售报告中）和一个结束日期（这样它就会在生命周期结束后从报告中删除）。使用正确的日期作为您的报告和应用程序的标准，您不会看到 whizbang，除非您应该看到数据，并且数据仍然存在（理论上应该是无限的）。
正如 Koistya Navin 所提到的，在某个时间点将数据移动到数据仓库也是一种选择，但这在很大程度上取决于您的“旧”数据有多大，以及您需要多长时间保持它随时可供访问。
我们的许多客户将数据在线保存 2 年。之后，它被移动到备份磁盘，但如果需要，它可以联机。
考虑添加一列“到期”或“生效日期”。这将允许您将产品标记为过时，但如果满足时间范围，报告将返回该产品。
通常最好将这些数据移动到单独的数据库（数据库仓库）并保持工作数据库的清洁。在数据仓库中，您的数据可以保存多年而不会影响您的应用程序。
参考：维基百科的数据仓库
我一直在寻找统治机构的目标。例如，美国国税局希望您保留 7 年的历史记录，或者出于安全原因，我们保留 3 年的日志信息等。所以我想您可以做两件事，确定您的数据的生命周期，我会说 3 年足够了，然后您可以添加 is_deleted 标志和日期，这样您就可以标记一些数据以尽早删除。
是的，所有数据都有生命周期。是的，它与您拥有的数据类型有关。
一些数据具有以秒为单位的生命周期（例如身份验证令牌），而另一些数据则具有虚拟永恒（比存储它的介质和格式更长，例如所有权记录）。
您将不得不更具体地了解您所设想的数据类型，或者在您自己的组织中进行人口普查以了解材料的通常生命周期。
我们的特殊风味各不相同。我们有一些数据（绝大多数）在 3 个月后会失效（硬产品限制），但可以在以后的任何日期恢复。
我们还有其他数据实际上是不朽的。
在实践中，我们提供的大部分数据都是新鲜的，并且经常需要几周，最多一个月，然后才会被零星使用。
“大量死数据”是多少？
由于处理能力和数据存储如此便宜，除非有充分的理由，否则我不会清除旧数据。您还需要考虑法律影响。大型（甚至小型）公司可能对旧数据有非常长的保留政策，以便在法官传唤他们时为自己节省数百万美元。
我会与您拥有的任何法律部门核实，并了解数据需要存储多长时间。这是最安全的赌注。
另外，问问自己删除旧数据有什么好处。唯一的好处是更整洁的数据库吗？如果是这样，我不会这样做。你会看到 10 倍的性能提升吗？如果是这样，我会这样做。不过，这确实是一个复杂的问题，我们很难掌握所有必要的信息来为您提供好的建议。
我有几个项目，客户想要所有的历史数据（可以追溯到 19 年前）。相当多的旧数据格式不正确，导入新系统将是一场噩梦。我们说服他们，他们不需要 10 年后的记录，但就像你说的那样，这一切都与你所保存的数据类型有关。
附带说明一下，数据存储现在非常便宜，如果它不影响您的应用程序的性能，我会把它留在原处。
[...] 但当然所有数据都有某种寿命？
没有任何一种我们可以有意义地谈论的寿命。许多数据一经创建或记录就毫无用处。这些数据可以立即丢弃而没有任何影响。另一方面，一些数据具有足够的价值，它将比托管它的当前系统寿命更长。如果亚马逊要完全替换他们当前的基础设施，他们存储的客户历史记录仍然非常有价值。
正如你所说，这是相对的。每种类型的数据都有自己的生命周期，与另一种数据的生命周期无关。没有有意义的“数据的平均寿命”。
我有存储大量死数据的潜力。（永远不会再次访问的数据）。
但是当他们执行这些报告时，他们会访问这些数据。
在此之前，您需要以某种形式保存数据。移动到另一张桌子或像您提到的那样进行切换。
呃...冒着过于简单化的风险...听起来使用 DateDeleted 而不是一点点可以解决您的保留时间问题。