Зачем кому-то использовать драгоценный камень иностранца?
Скорее всего, это вопрос нубов, так как люди используют этот драгоценный камень, и многим он нравится, но я не понимаю цели. Я смотрю на проект, и он был использован здесь много раз в таких местах, как t.references :foreign_key_table_name , :foreign_key => true, add_foreign_key :table :foreign_key_table_name, :optionsи в создании t.foreign_key :foreign_key_table_name, Надеюсь, что это не смущает, так как они вне контекста.
Но я не понимаю, как это отличается от того, что рельсы встроены в t.references :foreign_key_table_name или от меня просто добавив t.integer :foreign_key_table_name_id? это просто делает его более читаемым, давая понять, что это "внешний ключ"? Я мог бы просто добавить комментарий вместо драгоценного камня, если это так... Единственное преимущество, которое я вижу, это то, что вы можете перемещать такие параметры, как :dependent в миграции, а не в модели, но кого это волнует?
3 ответа
Некоторые механизмы базы данных поддерживают допустимые ограничения внешнего ключа: если кто-то пытается сохранить Child с parent_id из 5, но нет Parent с id 5, тогда сама база данных (не Rails) отклонит запись, если есть ограничение внешнего ключа, связывающее children.parent_id а также parents.id,
Внешний ключ также может указывать, что происходит, если родитель удаляется: например, в MySQL мы можем удалять или аннулировать зависимые записи, как это делает Rails с :dependentили даже просто отклонить удаление и выдать ошибку.
Поскольку не все движки баз данных предоставляют такую функциональность, Rails предлагает эмулировать :dependentи хорошо иметь его на программном уровне, чтобы зависимые дочерние записи могли запускать свои destroy обратные вызовы, когда родитель удален. Поскольку эта функция не зависит от движка и, следовательно, практически не зависит от схемы, Rails не обрабатывает создание / удаление внешних ключей. Это где foreigner приходит: если ваш движок поддерживает ограничения внешнего ключа, и вы хотите, чтобы это было более уверенно в целостности ваших данных, foreigner может помочь с этим.
Воскрешая старый вопрос здесь, но...
Наличие рельсов навязывает хорошие отношения внутри самих рельсов.
Однако, если ваш проект вырастет, чтобы иметь код, который также обращается к этим таблицам из других языков, это не будет иметь преимуществ от рельсов, навязывающих отношения. Эти ограничения внешнего ключа встраиваются в сами таблицы SQL, поэтому могут защитить код, не предназначенный для Rails.
Это также защитит вас, если вам нужно выполнить исправления данных или иным образом манипулировать вашими данными через собственный SQL.
Другая причина в том, что некоторые инструменты документирования для SQL смотрят на внешние ключи в БД, поэтому здорово иметь гем, который их генерирует. В Rails 4 добавлена возможность определять внешние ключи в той же миграции, которая создает таблицу с:
t.references :something, foreign_key: true
И генераторы сделают это для вас, если вы используете references тип. Rails добавляет индекс something_id по умолчанию при использовании foreign_key как это