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

Question

tl；博士--在底部，我问了几个关于智能数据库设计的一般性问题，这些问题不需要阅读全部内容。所以，你可以跳过，看看那些。谢谢!

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

我不太了解数据库是如何工作的，以及是什么使它们慢下来的，所以我非常感谢任何关于如何最好地完成这一任务的输入(如下面所概述的)，因为我在我所想到的方法中看到了冲突。

在我看来，在这里我有三条路可以走：

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 a user，如上面所述，但当我被选择成为一名choice的毕业生时，这些选项就剩下了。 (这有点类似于这篇较旧的文章讨论了如何通过将旧数据转移到一个新表来归档。这被认为是一种好的做法吗？对我来说很理想，但我不知道潜在的坏处)。 在我看来，这个选项保留了所有数据，同时使我的主Choice表不受kruft未选择数据的限制。不幸的是，它在数据库中添加了一个主要的复制，也增加了代码的复制(虽然我认为Option可以从Choice继承，这很奇怪，但无论如何)。

然而，所有这些观点都完全不了解关于数据库体系结构和效率的知识，如果我知道的话，我会觉得能够更好地处理这些权衡：

• 表中已删除的行是否像现有行一样减慢事务处理速度？较少?完全没有?在SQL数据库中，表大小在什么时候成为一个严重的问题？值得考虑吗？
• 删除数据的最佳实践是什么？这真是个坏主意吗？
• 关于重复表的最佳实践是什么？(即数据结构相同的表，由于若干原因，与原表不同)。
• 最广泛、最不恰当、最有用的问题是:如何处理这个问题，优化Choice表的效率？(但也尽可能避免重复和遵循最佳做法)。

谢谢!

Answer 1

以“.”作为前缀的小文件如何？因此，它被隐藏在用户主目录中(在unix中)。如果以可读格式输出选项，则可以轻松地读取和修改选项。

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