2索引合适吗？

Question

我有都涉及几个非常简单的问题，我不认为保证每个

1. 独立后，如果我有一个用户模型（设计GEM）同时包含“用户名”和“电子邮件“属性，而且都是独一无二的，我是否将add_index添加到他们两个或只有一个？对于这个特定的表，只需要一个键作为外键，我只是不知道我是否应该为它们添加_index。

2. 我该如何重新排序在我的表单前端发生的验证？现在，用户名的验证信息在底部，但是它是表单中的第一个字段，所以它们应该位于顶部。这是在我添加领域的设计宝石之后，所以即时猜测设计验证运行在我之前。

3. 它是否不愿意编辑设计宝石的数据库迁移文件，或者我应该为每个变更做轨道迁移？我的应用尚未投入生产，但我刚刚看到一些教程，其中大家都推荐这一步。

Answer 1

（1）该索引将用于从Users表中查找行，因此如果您要通过电子邮件查找用户，则可以添加电子邮件索引以及用户名。否则，用户名单应该没问题。

（3）是的，编辑一个已经运行的迁移文件是不可取的，因为它很难跟踪更改，并且最终可能会导致只能回滚编辑过的部分。因此，无论何时需要进行数据库更改，都应该创建新的迁移。但是，由于您的应用程序尚未投入生产，具体取决于您拥有多少数据，因此这样做可能没有太大的危害。你的来电。

Answer 2

对1：这取决于你想要成为多么严谨，以什么方式。一方面，既然在两个字段上添加一个唯一的约束/索引非常便宜且容易（我假设传统的SQL模式），为什么不呢？另一方面，一些rails纯粹主义者认为（有充分的理由），您应该放弃任何数据库供应商的具体情况，并在rails模型中强制执行所有约束，然后添加索引（而不是约束）作为性能优化。我是旧的skool，所以我更喜欢前者，但我也是纯粹主义者，所以我确保我的rails模型是正确的，我的应用程序从不依赖于数据库供应商的具体细节。

2：我会处理验证错误显示在视图层，即不要挂上它们运行的​​顺序 - 将所有验证视为原子操作。然后，在视图中，而不是只按照它们碰巧的顺序转储错误消息，重新排序哈希，甚至显式测试并输出每个键。它的可维护性稍差，因为如果添加新输入，则需要更新该视图代码。但是，这与尝试维持验证运行顺序的头痛相比是微不足道的。就我个人而言，我不相信错误信息的打印顺序甚至是相关的，但我知道是以一种错误的方式磨擦了一些人。

3：同意Sebi，不要编辑宝石或任何宝石提供的东西，也不要追溯编辑迁移。添加一个新的迁移是微不足道的，所以只需要做，然后转移到有趣的东西上。如果我是一个不在生产环境中的应用程序的唯一程序员，我会采取快捷方式，但只要它活着或者有另一个开发人员，我就会更加自律。而且，我花更多的时间来编写rails，我发现编写rails db迁移就像SQL一样容易或容易。