przejście z MySQL na PostgreSQL dla Ruby on Rails ze względu na Heroku

Typowe problemy:

1. Zachowanie GRUPUJ WEDŁUG. PostgreSQL ma dość ścisłą funkcję GROUP BY. Jeśli używasz klauzuli GROUP BY, każda kolumna w SELECT musi albo pojawić się w Twojej GROUP BY, albo być użyta w funkcji agregującej.
2. Obcinanie danych. MySQL po cichu skróci długi ciąg, aby zmieścił się w char(n) o ile twój serwer nie jest w trybie ścisłym, PostgreSQL będzie narzekał i sprawi, że sam skrócisz swój łańcuch.
3. Cytowanie jest inne, MySQL używa backticków do cytowania identyfikatorów, podczas gdy PostgreSQL używa podwójnych cudzysłowów.
4. LIKE nie uwzględnia wielkości liter w MySQL, ale nie w PostgreSQL. Skłania to wielu użytkowników MySQL do używania LIKE jako operatora równości ciągów bez uwzględniania wielkości liter.

(1) będzie problemem, jeśli użyjesz group AR metody w dowolnym zapytaniu lub GROUP BY w dowolnym surowym języku SQL. Przeprowadź wyszukiwanie column "X" must appear in the GROUP BY clause or be used in an aggregate function a zobaczysz kilka przykładów i typowych rozwiązań.

(2) będzie problemem, jeśli używasz kolumn ciągów w dowolnym miejscu w aplikacji, a modele nie sprawdzają prawidłowo długości wszystkich przychodzące wartości ciągu. Zauważ, że tworzenie kolumny string w Railsach bez określenia limitu faktycznie tworzy varchar(255) kolumna, więc w rzeczywistości istnieje niejawny :limit => 255 nawet jeśli nie określiłeś jednego. Alternatywą jest użycie t.text dla twoich ciągów zamiast t.string; to pozwoli ci pracować z dowolnie dużymi ciągami bez kary (przynajmniej dla PostgreSQL). Jak Erwin zauważa poniżej (i każdą inną szansę, jaką ma), varchar(n) to trochę anachronizm w świecie PostgreSQL.

(3) nie powinno stanowić problemu, chyba że masz w kodzie surowy kod SQL.

(4) będzie problemem, jeśli używasz LIKE w dowolnym miejscu w swojej aplikacji. Możesz to naprawić, zmieniając a like b do lower(a) like lower(b) (lub upper(a) like upper(b) jeśli lubisz krzyczeć) lub a ilike b ale pamiętaj, że ILIKE PostgreSQL jest niestandardowe.

Istnieją inne różnice, które mogą powodować problemy, ale te wydają się być najczęstszymi problemami.

Aby czuć się bezpiecznie, musisz przejrzeć kilka rzeczy:

• group połączeń.
• Surowy SQL (w tym wszelkie fragmenty w where połączeń).
• Weryfikacja długości ciągu w Twoich modelach.
• Wszystkie zastosowania LIKE.