Для приложений Rails я должен поставить проверку в БД, а также модель?

Question

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

Например, если электронное письмо является обязательным полем, могу ли я добавить validates :email, :presence => true к модели И :null => false к миграции?

А как насчет строк?Если у меня :length => { :maximum => 50 } в модели, я также хочу :limit => 50 в миграции?

Добавлять ли внешние ключи в базу данных для обеспечения ссылочной целостности?

Или это "Rails способ «сделать как можно больше в модели и оставить базу данных как« тупой »механизм персистентности?

Answer 1

Определенно добавьте: null => false.в противном случае ваш администратор базы данных может причинить вам вред.Ваше приложение Rails не единственное, что касается БД.

максимальная длина дает вам усиление памяти БД.определенно установите максимальную длину, но обязательно добавьте валидацию валидаций.В противном случае вы можете получить странные ошибки приложения.

внешние ключи хороши, но меньше используются в приложениях rails

Answer 2

Стандартным способом Rails Way является сохранение ограничений в коде Ruby.

У меня редко бывает такая роскошь, когда только Rails (или даже просто Ruby) прикасаются к БД ... И, честно говоря, даже просто люди, копающиеся в БД, могут вызвать проблемы ... поэтому я склонен использовать БД ограничения, потому что я не уверен, что данные когда-либо будут слишком хорошо подготовлены.

Answer 3

Обычно лучшая практика заключается в том, чтобы исключить как можно больше логики из БД. Добавление недействительной проверки в ваши миграции на самом деле не повредит и не поможет в этом аспекте сохранения логики. Если вы используете проверку модели, то большая часть вашего приложения должна пройти через это в любом случае. Это мойка в моей голове.

Где вы можете пойти за борт - это другие типы ограничений. Некоторые БД поддерживают все виды сумасшедших ограничений, которые лучше работают как валидаторы - валидаторы легче тестировать и запускать эти тесты в автоматическом режиме.

Если у вас есть несколько частей, которые касаются БД, и они не все рубиновые, то написание SOA-слоя для выполнения всей проверки и тому подобного в коде часто бывает полезно. Опять же, проще тестировать код, чем логику в БД.