Когда мне нужны модельные отношения, как мне защищаться от ошибок?

Question

У меня есть приложение с большим количеством отношений базы данных, которые зависят друг от друга, чтобы успешно управлять приложением. Шарнир в приложении - это модель, называемая «Расписание», но график будет вытаскивать «Блоки», «Сотрудник», «Идентификатор задания» и «Назначение» (кроме того, каждый блок также вытаскивает назначение из базы данных вместе с ним) собрать график сотрудников в течение дня.

Когда я построил приложение, я уделял большое внимание проверкам, которые гарантировали бы, что все части должны быть на месте, прежде чем все будет сохранено в базе данных. Это до настоящего времени получилось фантастически, и приложение было живым и стучало в течение почти 6 месяцев, обслуживая около 150 000 запросов в месяц без икоты или ошибок. До последней недели.

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

При разработке приложения так, как я заявляю, защищаете ли вы от возможного сбоя со стороны базы данных/валидации? И если да, то как вы программно защищаете его? Проверяете ли вы все отношения, чтобы убедиться, что он не равен нулю, прежде чем отправлять его в представление?

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

Answer 1

Я бы порекомендовал добавить database-enforced foreign key constraints и wrapping important groups of operations into transactions.

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

Answer 2

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

Я сомневаюсь, что проблема, с которой вы столкнулись, является ошибкой в ​​вашей базе данных. Скорее всего, в ваших проверках есть какой-то крайний случай, который вы упустили.

Answer 3

В дополнение к вашим проверкам и добавлению некоторых ограничений базы данных, как упоминалось в других ответах, вы также можете запустить фоновое задание, которое периодически подметает базу данных, ищущую сирот.

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

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

Answer 4

Я буду спорить с нетрадиционной мудростью. Ограничения, которые вы описываете, не входят в базу данных, они принадлежат вашему OO-коду.И это не так, что «база данных заблуждался», это, безусловно, верно, что приложение является то, что вставлена ​​неправильно проверенные данные.

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

В идеале вы должны быть способны для замены РСУБД некоторым другим общим хранилищем данных и до сих пор все функциональные логики должным образом активны и не изменяются в соответствующих других местах. Пользовательский интерфейс не должен разговаривать с DAL, тем более что он напрямую связан с исключениями базы данных.

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