RoR/AR：有关跨 Rails 环境管理不同 RDBMS 权限的建议
是否有在一个 Rails 应用程序下管理多个测试和生产数据库用户的推荐做法？我有一个 Rails 应用程序，有四个不同的数据库用户与之关联：
- 所有者，拥有应用程序架构的数据库用户
权限：几乎所有内容。 （这是维护/迁移帐户。） - app，为 Web 应用程序提供支持的数据库帐户
权限：读取大多数表和视图，写入一些临时缓存表。 - writer，提供数据的数据库帐户
权限：在几个表上写入。 - 审核员，记录数据库写入活动的数据库帐户
权限：拥有一些触发器和函数。
现在，我的迁移文件包含这些特定命名用户的 GRANT/REVOKE 逻辑。然而，在“开发”环境中，这些用户都使用同一个帐户通常很方便。此外，这些用户的硬编码名称可能与最终生产环境中已存在的数据库用户名冲突。
Is there a recommended practice for managing multiple testing and production database users under one Rails app? I've a Rails app with four different database users associated with it:
- owner, the DB user who owns the app schema
Permissions: Just about everything. (This is the maintenance/migration account.) - app, the DB account that powers the web application
Permissions: Read on most tables and views, write on some temporary caching tables. - writer, the DB account that feeds
Permissions: Write on a few tables. - auditor, the DB account that logs DB write activity
Permissions: Owns a few triggers and functions.
Right now my migration files contain GRANT/REVOKE logic for these specific, named users. However, in the "development" environment all it is often convenient for these users to all be the very same account. Additionally, the hardcoded names of these users may conflict with already-existing DB user names in the final production environment.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来您将需要为您拥有的每个用户类别（应用程序/编写器）管理 2 个不同的数据库连接。这通常是通过混合帮助程序来管理的，以将它们设置为需要使用它们的不同类别的模型。
您没有理由不能在开发环境中配置此功能，但是通过使用与生产环境完全相同的暂存环境来解决此类问题，您将获得最大的收益，您可以在其中对行为进行最终调整在某些内容被推送之前。
It sounds like you're going to need to manage 2 different database connections for each of the classes of users you've got (app/writer). This is often managed by mixing in helpers to set these up to different classes of Models that need to use them.
There's no reason you can't configure this in your development environments, but you'll get the most bang for the buck by using a Staging environment that exactly resembles your Production environment for issues like this, where you can do a final shakedown of behavior before something is pushed live.