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

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

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

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

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

источник

2011-01-05 Jason Swett

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

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

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

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

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

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

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

def self.up 
    execute <<EOS 

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

EOS 
    end

источник

2011-01-05 22:59:23

Хороший ответ. Могу ли я предложить использовать форму «<< - EOS» heredoc? Таким образом, вам не нужно выровнять все в столбец 0. – noodl

Да, это тоже вполне разумно - хотя - им немного странно и хотелось бы, чтобы мой SQL правильно выравнивался - особенно если писать несколько функций/триггеров в одном и том же миграция. –

Я думаю, что это то, что я буду делать. Просто из любопытства, означало бы это, что я не смогу создать мой стол и модель одним махом? Должен ли я написать определение таблицы в SQL, а затем отдельно создать подходящую модель? –

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

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

источник

2011-01-05 22:46:00 Heikki

я обнаружил, задавая один и тот же вопрос, на другой день, так что я сделал некоторые исследования и разбором моих выводов в an answer to an older but similar Stack Overflow question. Надеюсь, это полезно.

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

источник

2011-10-19 16:15:49

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

ответ

Смежные вопросы