Обычно внешние ключи в направляющих избегаются?
Направляющие не имеют никакого способа создать внешние ключи в миграциях (существуют плагины, чтобы сделать это, однако). Существует также много каскадных опций, таким образом, можно добраться, расположение каскадом удаляет, например.
Со всеми этими встроенными опциями действительно ли стоит создать внешние ключи в базе данных? Это - что-то, чего разработчики направляющих обычно избегают или что? Вы думали бы, были ли это методические рекомендации, что направляющие исходно поддерживали бы его.
2 ответа
Это что-то вроде священного вопроса, потому что DHH (создатель Rails) ранее заявлял, что он рассматривает базу данных как по существу гигантскую хеш-таблицу, поэтому пользуясь преимуществами некоторых вещей, в которых движки баз данных хороши, используя такие функции, как ограничения или хранимые процедуры, не считаются Пути Rails пуристами Rails.
Тем не менее, если вы хотите обеспечить целостность ваших данных, ближайших к данным, или если ваша база данных используется другими приложениями, то обязательно используйте один из этих плагинов для создания внешних ключей. В конце концов, какой вред это может нанести, верно?
Rails не мешает вам использовать ограничения внешнего ключа в вашей базе данных, он просто не выдает их вам по умолчанию. «Путь Rails» заключается в том, чтобы полагаться на Rails в управлении вашей базой данных, каскадном удалении, обеспечении ссылочной целостности и т. Д.
Есть несколько плагинов для добавления ограничений внешнего ключа к вашим миграциям, но я обычно предпочитаю добавлять их вручную. Предполагая, что вы создали миграции CreateUsers и CreatePosts, вы можете добавить миграцию «LinkPostsToUsers»:
# Assumes PostgreSQL
class LinkPostsToUsers < ActiveRecord::Migration
def self.up
execute "
ALTER TABLE posts
ADD CONSTRAINT fk_posts_user_id
FOREIGN KEY (user_id) REFERENCES users(id)
ON DELETE CASCADE
ON UPDATE CASCADE"
end
def self.down
execute "ALTER TABLE posts DROP CONSTRAINT fk_posts_user_id"
end
end