Внешние ключи в Rails 3

Я понимаю, что в соответствии с философией Rails проверки целостности данных должны выполняться на уровне приложения, а не на уровне базы данных. Как и многие другие разработчики, я с энтузиазмом не согласен.

Я нашел много дискуссий, посвященных этой проблеме, но все они кажутся старыми и, с тревогой, они, похоже, указывают на расходящиеся решения.

Я должен представить себе де-факто стандартный способ ограничения внешних ключей в Rails 3. Однако, что бы это ни было (если оно существует), похоже, задушено всеми прошедшими обсуждениями, потому что я не могу его найти.

Являются ли разработчики Rails этим пунктом в основном на одной странице с внешними ключами? Если это так, я хотел бы знать, как они обычно обрабатываются.

Ответ 1

Именно по этой причине я (и люди, которые написали Enterprise Rails - http://oreilly.com/catalog/9780596515201), рекомендуют вам писать весь вниз в SQL.

Преимущества:

Возможность добавления внешних ключей при создании таблицы - без отдельной таблицы изменений
Он позволяет использовать типы полей конкретной базы данных - например, tsvectors
Он позволяет добавлять различные типы индексов - например, Gin или Gist
Он позволяет вам писать функции и/или триггеры
Вам не обязательно помнить, какой тип DSL относится к типу поля SQL - например,: Число

Есть недостатки:

Это не агностик базы данных (кто заботится и как часто вы будете менять свою базу данных?)
Это не Ruby (но каждый хороший разработчик Rails должен знать SQL, верно?)

Но, в целом, я считаю, что преимущества перевешивают недостатки.

Быстрый пример:

  def self.up
    execute <<EOS

create table .... (
  ....
);

EOS
   end

Ответ 2

http://guides.rubyonrails.org/migrations.html#active-record-and-referential-integrity

"Хотя Active Record не предоставляет каких-либо инструментов для непосредственного взаимодействия с такими функциями, метод execute может использоваться для выполнения произвольного SQL. Также существует ряд плагинов, таких как foreign_key_migrations, которые добавляют поддержку внешнего ключа для Active Record".

Ответ 3

Я обнаружил, что задаю тот же вопрос на днях, поэтому сделал некоторые исследования и сопоставил свои результаты в ответе на более старый, но похожий вопрос о переполнении стека. Я надеюсь на это.

Кстати, когда вы говорите, что вы "с энтузиазмом не согласны", что проверки целостности данных должны выполняться на уровне приложений в отличие от уровня базы данных, я предполагаю, что вы имеете в виду, что они должны выполняться на обоих уровнях, а не только на база данных. Надеюсь, я прав, думая, что практически все согласны с тем, что проверка целостности на уровне приложений - это хорошая вещь, и что обсуждаемая только тема обсуждается, следует ли их дополнительно делать в базе данных.