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

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

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

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

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

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

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

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

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

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

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

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

Оба вида ошибок значения по умолчанию могут быть отменены разработчиками клиента. Проще установить барьеры для разработчиков, используя дефектные значения по умолчанию на среднем уровне. НАСКОЛЬКО МНЕ ИЗВЕСТНО, никакая база данных не позволяет вам требовать, чтобы поле принимало значение по умолчанию на INSERT. (Изменить: TRIGGER может обеспечить это, но вам нужно будет скопировать значение по умолчанию в свой триггер, и TRIGGER перезапишет любые вставленные значения по умолчанию) Примером того, где это может иметь значение, являются различные токены, которые люди используют для неизвестного, но будущего date, или неизвестная, но прошедшая дата, или это может иметь значение, используют ли они GETDATE (), который включает время, или они используют дату по умолчанию с годом, месяцем, днем ​​и без времени.

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

Как и в случае с большинством аргументов «код против базы данных», это зависит.

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

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

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

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

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

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

ПРИМЕР

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

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

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

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

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

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

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

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

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

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