mysql - 为了 Heroku,从 MySQL 切换到 PostgreSQL for Ruby on Rails

标签 mysql ruby-on-rails ruby-on-rails-3 postgresql heroku

我正在尝试将全新的 Ruby on Rails 应用程序推送到 Heroku。目前,它位于 MySQL 上。看起来 Heroku 并不真正支持 MySQL,因此我们正在考虑使用他们支持的 PostgreSQL。

我认为这有多难?我需要做什么才能做到这一点?

再次请注意,我的数据库目前(开发和生产)完全是空的。

最佳答案

常见问题:

  1. GROUP BY 行为。 PostgreSQL 有一个相当严格的 GROUP BY。如果您使用 GROUP BY 子句,则 SELECT 中的每一列都必须出现在 GROUP BY 中或用于聚合函数。
  2. 数据截断。除非您的服务器处于严格模式,否则 MySQL 会安静地截断一个长字符串以适应 char(n) 列,PostgreSQL 会提示并让您自己截断字符串。
  3. 引用不同,MySQL 使用反引号来引用标识符,而 PostgreSQL 使用双引号。
  4. LIKE 在 MySQL 中不区分大小写,但在 PostgreSQL 中不区分大小写。这导致许多 MySQL 用户使用 LIKE 作为不区分大小写的字符串相等运算符。
如果您在任何查询中使用 AR 的 group 方法或在任何原始 SQL 中使用 GROUP BY,

(1) 将成为一个问题。搜索 column "X"must appear in the GROUP BY clause or be used in an aggregate function,您将看到一些示例和常见解决方案。

(2) 如果您在应用程序中的任何地方使用字符串列并且您的模型没有正确验证所有 传入字符串值的长度,那么

(2) 将成为一个问题。请注意,在 Rails 中创建一个字符串列而不指定限制实际上会创建一个 varchar(255) 列,因此实际上有一个隐式的 :limit => 255 即使你没有指定一个。另一种方法是对字符串使用 t.text 而不是 t.string;这将使您可以使用任意大的字符串而不会受到惩罚(至少对于 PostgreSQL)。正如 Erwin 在下面(以及他得到的每一次机会)所指出的那样,varchar(n) 在 PostgreSQL 世界中有点不合时宜。

(3) 应该不是问题,除非您的代码中有原始 SQL。

如果您在应用程序中的任何地方使用 LIKE,

(4) 将成为一个问题。您可以通过将 a like b 更改为 lower(a) like lower(b)(或 upper(a) like upper(b) 如果你喜欢喊)或 a ilike b 但要注意 PostgreSQL's ILIKE是非标准的。

还有其他差异可能会导致麻烦,但这些似乎是最常见的问题。

你必须回顾一些事情才能感到安全:

  • 群组 通话。
  • 原始 SQL(包括 where 调用中的任何片段)。
  • 模型中的字符串长度验证。
  • LIKE 的所有用途。

关于mysql - 为了 Heroku,从 MySQL 切换到 PostgreSQL for Ruby on Rails,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8736041/

相关文章:

java - 调试 MySQL 字符集错误

mysql SELECT 并汇总如果列不为空

ruby-on-rails - #<RSpec::Core::ExampleGroup::Nested_1:0x0000000a4b3a98> 的未定义方法 `disallow_value'

ruby-on-rails - 每次迁移后,架构文件中的外键都会被删除

ruby - Ruby on Rails 3.0 中的单表继承和路由

ruby-on-rails - 升级ruby和rails版本后has_many关系隐式转换错误

ruby-on-rails-3 - Rails 标记日志记录

php - MySQL 通过 "oe"、 "ae"、 "ue"找到元音变音

mysql - 将 UTF-8 格式的批量 CSV 数据导入 MySQL

ruby-on-rails - 如何计算平均请求持续时间?