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

Ответ 1

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

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

Не позволяйте приложению обрабатывать ваши проверки - оставьте это в базе данных!

Плюс это делает ваш оператор вставки SQL намного более компактным и средним, если вам не нужно указывать все "очевидные" значения по умолчанию, например "getdate()" для столбца даты LastChangedOn и т.д.

Ответ 2

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

Ответ 3

Значения кода по умолчанию проще для модульного тестирования.

Значения по умолчанию для кодов поддерживают несколько сценариев. Стандартные значения столбца DB - это один размер. Например, значения столбцов базы данных БД могут различаться в зависимости от типа клиента.

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

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

Оба типа дефолтов могут быть подорваны разработчиками-клиентами. Легче настроить барьеры для разработчиков, использующих дефектные значения по умолчанию в среднем уровне. AFAIK, никакая база данных не позволяет вам потребовать, чтобы поле принимало значение по умолчанию для INSERT. (Edit: TRIGGER может применить это, но вам придется скопировать значение по умолчанию на ваш триггер, а TRIGGER будет перезаписывать любые вставленные значения по умолчанию). Пример того, где это может иметь значение, - это использование различных токенов для неизвестного, но будущего дату или неизвестную, но прошедшую дату, или может иметь значение, если они используют GETDATE(), которая включает время или если они используют дату по умолчанию с годом, месяцем, днем ​​и отсутствием времени.

Я бы рекомендовал убедиться, что значения по умолчанию существуют там, где они имеют смысл в БД, но фактически не используют их. БД по умолчанию должны быть по умолчанию в последнем случае, а значения по умолчанию должны быть прочно в среднем уровне (т.е. Хранимые procs, уровень доступа к данным). Столбец DB по умолчанию подобен обработчику исключений - когда кто-то случайно забыл указать значение, какое значение следует использовать для предотвращения повреждения данных?

Ответ 4

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

Пример

Представьте, что у вас есть таблица с миллионом или несколькими строками. В этой таблице есть столбец datetime, заполненный, возможно, в 5% случаев. С течением времени объем памяти, который вы сохраните, сохраняя значение NULL, сделает необходимые проверки по умолчанию более чем достойными.

Ответ 5

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

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

Итак, представьте, что у вас есть код статуса сотрудника, который может быть "P" (прогноз), "A" (активный), "T" (завершен) или "R" (отставке). Вы должны указать на уровне базы данных, будут ли люди вводить систему как "P" или "A", например (или, возможно, пятый код для Unassigned). Но ваше приложение может и должно требовать от пользователя создания записи сотрудника выбрать один из параметров из (например) группы переключателей и использовать это значение при вставке записи.

Ответ 6

Как и в большинстве аргументов "code vs database", это зависит.

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

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

Также: Если вы хотите получить дешевый ответ - спросите у человека, который отвечает за указание (и документирование) ваших моделей данных. Если у вас его нет, начните паниковать.

Ответ 7

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

Ответ 8

Если вас беспокоит целостность данных (а если у вас нет базы данных?), вам понадобятся значения по умолчанию в базе данных, где они принадлежат. Сделать это только в коде безответственно. Данные попадают в базы данных из других источников, кроме кода приложения.

Ответ 9

Базы данных предназначены для записи утверждений факта.

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

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

Обработка значений по умолчанию на уровне презентации и нигде больше. И обрабатывайте их таким образом, чтобы пользователь не мог видеть данные, которые он представляет (ВСЕ данные!).

Ответ 10

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

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

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