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

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

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