Необходимо ли осуществить ограничения на уровне базы данных, а также прикладном уровне?

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

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

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

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

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

С точки зрения ООП, база данных как в Объекте/Агенте, в большей системе и это должно быть ответственно за себя. Это включает необходимую потребность проверить вход.

Если Вы не осуществите, по крайней мере, основную целостность в базе данных, в какой-то момент недопустимые данные войдут. Возможно, из приложения. ошибка, возможно, от кого-то тянущего консоль SQL, безотносительно. И затем Вы добираетесь, чтобы узнать, что Ваше приложение имеет интересные виды отказа, когда невозможное ("все записи B должен иметь запись! что Вы подразумеваете, что это не существует?"), происходит.

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

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

дБ

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

Вы не можете сделать всего в дб, но можно сделать много. Защитите данные.

бизнес-уровень

, Перемещающий уровень вверх, у Вас есть бизнес-логика. Обычно это - Ваша точка интеграции с другими приложениями (веб-сервис, Ваш собственный UI, и т.д.). Здесь бизнес-логика в закодированном в приложение. Вещи как то, если продукт имеет дату окончания x, то не может также произойти в y, если y имеет различную дату окончания.

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

также трудно выразить в базе данных, другие 'правила' как 'новые пользователи имеют дату окончания срока действия 1 года, если они от Arkensas, 2 года иначе, если у них нет 3 детей, и одного из них называют Barry'. Мы можем смеяться над этим примером, но закаленный программист скажет Вам, что бизнес-логика является одним из самых больших оксюморонов вокруг.

ui

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

UI знает для поиска продуктов с X, если пользователь уже выбрал виджет Y. UI знает, что описание требуется, и что количество объекта> 0 и < 100 (В этих примерах хороший UI будет полагаться на бизнес-слой для сообщения его, например, минута и макс., но UI все еще знает об отношениях)

В веб-UI мы также добавляем клиентский сценарий, который снова копирует логику в серверном коде. Мы используем клиентский сценарий, чтобы сделать, чтобы лучший пользователь испытал, но в конце не доверяют ничему, что прибывает от клиента (сценарий может быть выключен, поля формы, которыми вручную управляют, и т.д.)

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

Да для обоих. Я узнал это в своем последнем месте. У нас были системы Дельфи прежней версии с sybase базами данных. Новая система была.NET и SQL-сервером. Один конкретный сотрудник был только ответственен за перевод sybase базы данных к базе данных SQL-сервера для клиентов, которые хотели обновления новой системы.NET. Он никогда не работал с кодом приложения.NET и поэтому никогда не видел ограничения данных на прикладном уровне.

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

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

Прежде всего, за эти годы я переместился от того, чтобы быть 100%, убежденными в реализации ограничений в DBMS к тому, чтобы стараться избегать его в целом: Я хочу всю свою бизнес-логику на том же слое.

, Во-вторых, я работаю много с направляющими, и миграции ActiveRecord не допускают много резидентного дб ограничительного определения вне размера поля и NULL_ness.

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

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

, Если Вы создаете новое приложение с ожиданием, что другие приложения получат доступ к данным, тогда подход собирается зависеть от того, как те другие приложения будут созданы. Снова, в направляющих, необходимо, вероятно, смотреть на способы совместно использовать модели, в этом случае тот слой должен быть достаточным. Если Вы не можете отклонить другие стили реализации от прямого доступа до Ваших данных, то Вы вернулись к дублированию. Мое предпочтение должно было бы попробовать - очень трудно - чтобы запретить прямого доступа дб к тем приложениям и стремиться обслужить их через (надо надеяться, УСПОКОИТЕЛЬНЫЙ) веб-сервис, так, чтобы можно было управлять целостностью данных на уровне бизнес-логики.

, Если третье лицо (внутренний или иначе) приложение имеет доступ DDL к Вашей схеме, то прекратите волноваться о проблеме - Вы уже потеряли контроль над своими данными, и Вы завинчены!

Мое персональное предпочтение должно осуществить основную проверку на слое базы данных и затем использовать методы самоанализа для пузырения тех ограничений до прикладного уровня как значения по умолчанию (соглашение по конфигурации). Если у меня будет некоторое взаимодействие с пользователем в форме и т.п., которая необычна тогда, то я переопределю значения по умолчанию, которые я получил от базы данных с любым новым поведением, в котором я нуждаюсь. Это помогает мне сохранить самую основную проверку, прежде всего, СУХО в слое базы данных, в то время как я делаю более сложную проверку (т.е. формат телефонного номера) на прикладном уровне.

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

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

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

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

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

Это зависит.

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

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

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

кроме того, необходимо объявить "ссылочное" ограничение для каждого внешнего ключа. Это осуществляет ссылочную целостность. С достойным DBMS необходимо быть в состоянии осуществить ссылочную целостность, даже когда внешний ключ является дополнительным, другими словами, могло бы быть ПУСТЫМ. АННУЛИРУЕТ, Конечно, ни к чему не относятся.

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

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

относительно правил проверки, которые запрещают отсутствующие значения (АННУЛИРУЕТ), нет никакого вреда в реализации их и в приложении и в базе данных. Во многих случаях это - правильный поступок. Так же с проверками принадлежности к диапазону.

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

Если Вы следуете, школа Jeff Atwood базы данных является просто немым хранением данных & поисковая система тогда Вы поместили бы всю проверку в прикладной уровень.

Однако я нахожу, что приложения похожи на маленьких детей. Неконтролируемый они бросят все вокруг комнаты. Это будет до родителей для разгребания бардак. В этом случае это будет DBAs выполнение очистки.

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

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

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

2. , Если Вы выполняете операции CRUD на представлении. Триггеры обязательны для вставить/обновить/удалить операций.

я склонен выполнять основную проверку в приложении. Таким образом, пользователю дают непосредственную обратную связь, что что-то неправильно. Сложная проверка, которая требует поиска связанных таблиц, вероятно, лучше всего сделана в базе данных (а также простая проверка, которую приложение делает). Я утверждал бы, что некоторые формы проверки почти невозможно гарантировать на прикладном уровне, не используя сложные стратегии блокировки.

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

Jeff Atwoods этого мира предложил бы, чтобы Вы записали веб-сервис что все использование приложений для передачи с. Веб-сервис выполняет подтверждение правильности данных. Выполнение этого позволяет базе данных оставаться немым контейнером устройства хранения данных, таким образом позволяя Вам переключить механизмы базы данных. В действительности Вы редко изменяете механизмы базы данных (если Вы не начали с Microsoft Access!). Если Вы пишете веб-сервисы просто для централизации подтверждения правильности данных тогда я thnk, Вы идете за борт.

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

нет никакой гарантии, что багги (или злонамеренный) слой "бизнес-логики" не вставит токсичные данные в Ваши таблицы. Конечно, если можно доверять другим слоям, Вам, вероятно, не будет нужен он. Но я работаю в мейнфреймовом магазине, где DBAs должны всегда решать проблемы, вызванные молодыми ничтожествами Java, развертывающими их содержащий ошибки код к производству без соответствующего (кто-либо?) тестирующий:-).

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

Я соглашаюсь, что ответ на этот вопрос зависит от среды.

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

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