我有几个非常简短的问题都是相关的，我不认为每个问题都有一个单独的帖子
如果我有一个包含“用户名”和“电子邮件”属性的用户模型（Devise gem），并且两者都是唯一的，那么我是add_index还是只有一个？这个特定的表只需要一个键作为外键，我只是不知道我是否应该为它们添加add_index。
如何重新排序表单前端发生的验证？现在，用户名的验证消息位于底部，但它是表单上的第一个字段，因此它们应位于顶部。这是在我将字段添加到设计宝石之后，所以我猜测设计验证首先在我之前运行。
编辑devise gem的数据库迁移文件是不是不赞成，还是应该为我想要进行的每次更改执行rails g migration？我的应用程序尚未投入生产，但我刚看到一些教程，每个人都推荐这一步。
答案 0 :(得分：1)
（1）索引将用于从Users表中查找行，因此如果您要通过电子邮件查找用户，则可以添加电子邮件索引和用户名。否则单独用户名应该没问题。
（3）是的，编辑已经运行的迁移文件是不受欢迎的，因为很难跟踪更改，并且最终可能无法回滚您编辑的部分。因此，您应该在需要进行数据库更改时创建新的迁移。但是，由于您的应用尚未投入生产，具体取决于您拥有的数据量，因此这样做可能没有太大的危害。你的电话。
答案 1 :(得分：1)
开1：这取决于你想要的严谨程度和方式。一方面，因为它在两个字段上都是如此便宜且易于添加唯一约束/索引（我假设是传统的SQL模式），为什么不呢？另一方面，一些铁路纯粹主义者认为（有充分的理由）你应该放弃任何数据库供应商细节并在rails模型中强制执行所有约束，然后添加索引（而不是约束）作为性能优化。我是老skool，所以我更喜欢前者，但我也是纯粹的，所以我确保我的rails模型是正确的，我的应用程序从不依赖于db供应商细节。
On 2：我将处理视图层中的验证错误显示，即不要挂起它们运行的顺序 - 将所有验证视为原子操作。然后，在视图中，不是按照它们碰巧的顺序转储错误消息，而是重新排序哈希值，甚至显式地测试和输出每个键。它的可维护性稍差，因为如果添加新输入，则需要更新该视图代码。但是，与尝试维持验证运行顺序的头痛相比，这是微不足道的。就个人而言，我不相信错误信息打印的顺序甚至是相关的，但我知道是以错误的方式摩擦了一些人。
On 3：同意Sebi，不要编辑宝石或任何宝石提供的内容，也不要追溯编辑迁移。添加一个新的迁移是微不足道的，所以就这样做，继续讨论有趣的东西。如果我是一个没有投入生产的应用程序的唯一程序员，我会选择快捷方式，但是一旦它存在或者有另一个开发人员，我就会更加自律。而且，我花在编程rails上的时间越多，我发现编写rails db迁移就像SQL一样简单或容易。