Сразу скажу: решение не пройдет на всех хостингах, потому как вызывать сторонние процессы или shell-команды может быть запрещено настройками сервера! Быстрое и простое решение было таким:

Read the rest of this post »

Итак, есть проект. В нем порядка 70 миграций. В них никто не задумывался о UTF8, потому при создании таблиц по дефолту создаются они с collation = latin1_general_ci. После чего русский выводится как "????". Смог полечить следующим образом: в файле /etc/mysql/my.cnf прописать [cc lang="ruby"] set-variable=default-character-set=utf8 set-variable=default-collation=utf8_general_ci [/cc] Все таблицы создались как положено в UTF8, я счастлив.

См. предыдущий пост, там приведен пример. А теперь об ограничениях еще раз. У каждого ограничения задается имя. Например, CONSTRAINT `Ref_02`. И это имя должно быть УНИКАЛЬНЫМ во всей БД. Чтобы посмотреть, почему что-то не работает при вставках/удалениях, да еще и ругается на то, что это ошибка InnoDB, можно посмотреть используя команду [cc lang="mysql"] show innodb status; [/cc] из консоли mysql (вероятно, сделав SQL-запрос через phpmyadmin тоже пройдет, но меня это не сильно интересовало). А вот пример проблемы и указатель на ее решение. Проблема: мускуль ругается на ошибку error InnoDB 121. Что это за ошибка я так внятно и не нашел, но немного покопавшись и методом тыка нашел, почему она возникает. Кстати, она не отображается в show innodb status. А ошибка, собственно, из-за повторения имени CONSTRAINT'a. Как я говорил, оно должно быть уникальным. И если вы получили ее, а таблицы вставить надо, надо всего лишь сменить имя CONSTRAINT'a.

В университете в свое время у нас был курс по БД. Опирался он на Oracle. Но принципы и поняти были совсем общие. Так вот, там нам рассказывали по "ограничения целостности БД". В двух словах, что это такое, а потом, как это работает в MySQL и какие ошибки при этом случаются.

Read the rest of this post »