Rails 应用程序 - 更好地保留或删除过时的数据

Question

tl;dr - 在底部，我问了几个关于智能数据库设计的一般性问题，这些问题不需要阅读全部内容。因此，请随意跳过并查看这些内容。谢谢！

我正在构建一个 Rails 网络应用程序，在该应用程序中，在一些用户输入后，我会生成许多选项，用户可以从中选择一个，然后将其保存并与用户关联。这种选择可能会在选项生成后很长时间发生——因此需要保存选项——但一旦做出选择，所有“不正确”的选项都不再相关。

我对数据库的工作原理以及降低它们速度的原因知之甚少，因此鉴于我在我想到的方法中看到的冲突，我非常感谢任何关于如何最好地实现这一点的意见（如下所述） .

在我看来，我可以在这里采取三种方式：

1. 使选项只是Choice 模型的实例，通过belongs_to/has_many 与用户关联。当用户选择一个时，它的id 被声明为用户的choice_id（并且，其他选项可能与用户解除关联）。

   我看到的主要问题是Choice 表的大小会呈指数增长。这是我的应用程序中的一个主要表格，我想尽可能快地保持它。

2. 根据用户输入，我生成并保存 5 个 Choice 对象，所有这些对象都是 belong_to 用户，作为 options。然后，当用户选择时，删除四个，第五个关联为该用户的单个choice

   在我看来，不利的一面是我最终会在数据库中得到很多“空”行，因此最高的choice_id 明显大于数据库中choices 的数量。我最近工作的一位老板建议永远不要删除数据，这显然与这种方法相冲突。

3. 我为Option 模型创建了一个单独的表，它在几乎所有方面都与Choice 模型相同，因为选项需要完全丰富的替代品才能进行选择。这些选项belong_to 和user，如上所述，但是当我选择毕业成为choice 时，它们将保留。

   （这有点类似于this older post's discussion of archiving by moving old data to a new table。这被认为是一种好的做法吗？对我来说似乎很理想，但我不知道潜在的缺点）。

   如我所见，此选项保留所有数据，同时保持我的主要 Choice 表不受 kruft 未选择数据的影响。不幸的是，它在数据库中添加了主要重复，以及代码重复（尽管我想我可以让Option 只是从Choice 继承，这很奇怪，但无论如何）。

然而，所有这些观点都完全没有关于数据库架构和效率的知识，如果我知道的话，我会觉得能够更好地权衡取舍：

• 表中已删除的行是否会像现有行一样减慢事务处理速度？较少的？有吗？表大小在什么时候会成为 SQL 数据库中的一个严重问题？值得考虑吗？

• 关于删除数据的最佳做法是什么？这真的是个坏主意吗？

• 关于重复表的最佳做法是什么？ （即具有相同数据结构的表，由于多种原因，其处理方式与原始表不同）。

• 最广泛、最不适合和最有帮助的问题：您将如何处理这个问题，优化Choice 表的效率？ （而且，尽可能避免重复并遵循最佳实践）。

谢谢！

Answer 1

以'.'为前缀的小文件怎么样？因此它被隐藏（在 unix 中）放置在用户主目录中。如果您以可读的格式输出您的选项，则可以轻松阅读和修改它们。

您只想在性能或功能证明合理的情况下使用数据库。如果您要求用户使用必须安装的数据库，而客户可能不喜欢这样做。