Rails 是否有工具可以验证数据库的引用完整性？
应用程序存在错误或在更新时出现错误，其中一些隐藏的错误在数月或数年后才被检测到，产生孤立的记录、无处指向的密钥等，即使使用适当的测试套件也是如此。
尽管 Rails 没有在数据库级别强制执行引用完整性 - 并且出于其他地方讨论的一些充分原因，它将保持这样 - 拥有可以检查数据库是否处于一致状态的工具仍然会很好。
由于模型描述了“应该是什么”，因此离线工具不可能验证所有数据的完整性吗？它可以在备份数据之前定期运行，或者只是为了让开发人员睡个好觉。
有这样的事吗？
Applications have bugs or get bugs when updated, some hidden that they get detected months or years later, producing orphaned records, keys pointing nowhere etc. even with proper test suites.
Allthough Rails doesn't enforce referential integrity on the database level - and for some good reasons discussed elsewhere it will stay like that - it would still be nice to have tools that can check if the database is in a consistent state.
Since the models describe what 'should be', wouldn't it be possible that an offline tool validates the integrity of all the data. It could be run regularly, before backing up data or just for the sake of the developers good sleep.
Is there anything like this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不知道有这样的工具。至少您意识到引用完整性危险的危险。那么为什么要让自己受苦呢？正如 dportas 建议的那样，首先使用外键引用。
要在迁移中使用它，请添加如下内容：
使用户的 language_id 列引用语言表中的有效行。
根据您的 DBMS，这甚至会自动为您创建索引。还有 Rails 插件（查看 pg_on_rails），它们为这些任务定义了易于使用的别名函数。
仅检查备份文件的完整性是没有意义的，因为那时错误已经发生，并且您的数据可能已经混乱了。 （我去过那里）
另一方面，当使用如上所述的外键约束时，每一个会破坏完整性的操作都会失败。
可以把它想象成当你感到疼痛（=做手术）时去看牙医，而不是用神奇的牙膏刷一次牙，保证你的牙齿在你的余生都很好。
另一件需要考虑的事情是：应用程序中的错误将更容易定位，因为尝试插入损坏数据的代码将引发异常。
所以请使用外键约束。您可以轻松地将这些语句添加到现有数据库中。
I don't know of such a tool. At least you are aware of the dangers of referential integrity hazards. So why make yourself suffer? Just use foreign key references in the first place, as dportas suggested.
To use it in a migration, add something like this:
to make the language_id column of users reference a valid row in the languages table.
Depending on your DBMS this will even automatically create an index for you. There are also plugins for rails (check out pg_on_rails) which define easy to use alias functions for those tasks.
Checking the integrity only on the backup file is pointless, as the error has already occured then, and your data may be messed up already. (I've been there)
On the other hand, when using foreign key contraints as stated above, every operation which will mess up the integrity will fail.
Think of it as going to the dentist when you feel pain (=having surgery) vs. brushing your teeth ONCE with a magical tooth paste that guarantees that your teeth will be fine for the rest of your life.
Another thing to consider: An error in your application will be much more easier to locate, because and exception will be raised at the code which tries to insert the corrupt data.
So please, use foreign key contraints. You can easily add those statements to your existing database.
使用 DBMS 来实施 RI 怎么样？您不需要 Rails 来为您做这件事。
How about using the DBMS to enforce RI? You don't need Rails to do that for you.