或者换句话说，有没有理由不在我的所有模型上使用它？
某些背景信息：is_paranoid是一个宝石，可以调用destroy设置deleted_at时间戳而不是删除行（并调用find排除非行null deleted_at s）。
我发现这个功能非常有用，我开始将它包含在每个模型中 - 难以删除记录太可怕了。这有什么坏事吗？是否应该在Rails中默认打开此功能？
答案 0 :(得分：2)
Ruby不适合害怕自己代码的懦夫！
在大多数情况下，您确实想要完全删除记录。考虑一个包含两个其他模型之间关系的表。当您不想使用deleted_at时，这是一个明显的情况。
另一件事是你的数据库设计方法有点像红宝石。当您必须为表格编写更复杂的查询而不仅仅是deleted_At时，您将需要处理所有这些finds内容。当你的应用程序的数据库占用大量空间时，你肯定会用hacky SQL查询替换漂亮而有光泽的ruby代码。您可能希望丢弃此列，但是 - oops - 您已经在某处使用了deleted_at逻辑，并且您将不得不重写应用程序的较大部分。疑难杂症。
在最后一个地方，实际上当删除时事物消失似乎很自然。而建模的重点在于模型试图用机器可读的术语表达那里发生了什么。默认情况下，您删除记录并永久传递。并且只有deleted_at可能是自然的原因是以后要恢复记录或者应该防止类似记录与原始记录混淆（用户表最有可能是您想要使用它的地方）。但在大多数模特中，这只是偏执狂。
我想说的是，恢复已删除记录的合理性应该是明确表达的意图，因为它不是人们通常所期望的，因为有些情况下隐含使用它容易出错而且只是增加了一小部分开销（与维护created_at列不同）。
当然，在许多情况下，您希望还原记录的删除（特别是在意外删除有价值的数据导致不必要的支出时）。但是要利用它，你必须修改你的应用程序，添加表单等等，所以将另一个行添加到你的模型类中不会有问题。当然还有其他方法可以实现存储已删除的数据。
所以恕我直言，这是每个模型的一个不必要的功能，应该只在需要时开启，并且这种增加模型安全性的方式适用于特定模型。这意味着不是默认。
（这个过去受到railsninja的宝贵评论的影响。）
答案 1 :(得分：1)
@Pavel Shved
对不起但是什么？ Ruby不是因为懦夫害怕代码？这可能是我听过的最荒谬的事情之一。当然在连接表中你想删除记录，但是一个连接模型有多少通过，也许不是。
在商业应用程序中，不用硬删除内容，用户犯错误，很有意义。
你的很多回应，帕维尔，都是一种运球。在你需要的地方使用SQL并没有什么可耻的，以及如何使用deleted_at导致这个庞大的重构，我对此感到茫然。
@Horace我不认为is_paranoid应该是核心，不是每个人都需要它。虽然这是一个很棒的宝石，我在我的工作应用程序中使用它并且效果很好。我也相当肯定它并没有强迫我在我不需要的时候使用sql，而且由于它存在，我在将来看不到一个大的重构器。在需要时使用它，但它应该是一个宝石。