Каковы преимущества размещения значения по умолчанию в столбце?

Question

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

Я ищу преимущества настроек по умолчанию для колонок с точки зрения разработчиков. Спасибо за ваши комментарии.

Answer 1

Помогает с версионированием. Например, если старый код (операторы INSERT) ожидает таблицу с 10 столбцами, и этот старый код должен работать с новой таблицей с 12, то вам нужно будет указать значение по умолчанию для новых столбцов или сделать новые столбцы обнуляемыми .

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

Answer 2

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

Answer 3

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

Преимущество # 1 : если у вас есть таблица с 2 столбцами информации о пользователе и 20 столбцами полей tinyint / boolean, допустим, они являются настройками конфиденциальности, и вы приступаете к созданию новой записи в этом таблица, без значения DEFAULT вам нужно будет указать каждый столбец в вашем запросе. Вероятно, есть общие настройки, которые вы хотите, чтобы эти записи имели по умолчанию, и вы можете настроить их, используя значения DEFAULT. Когда вы INSERT записываете, вам нужно только указать два поля информации о пользователе, и вуаля, ваша запись создается с хорошим набором общих настроек конфиденциальности. После этого вы можете настроить флаги индивидуально.

Преимущество № 2 : прямая совместимость! Если в вашем коде есть куча INSERT с, а затем добавлены некоторые столбцы, вам придется вернуться и изменить все эти INSERT s, если вы не указали значение DEFAULT (при условии, что, как обычно, NULL s не собираются его сокращать). Часто нет необходимости обновлять старый код для нового столбца (поскольку старый код по своей природе не заботится о новом столбце), так что это будет огромная боль в @ $$ if Вы должны были начать возвращаться и обрабатывать каждый новый столбец в вашем коде, как он появился.

Answer 4

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

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

Answer 5

Значение по умолчанию значительно упрощает вставку новых строк в таблицу - все столбцы со значением по умолчанию не нужно явно указывать и снабжать значением в инструкции INSERT, если это значение по умолчанию в порядке (например getdate() для столбца даты "LastChangeOn".

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

Марк

Answer 6

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

Answer 7

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

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

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

Answer 8

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

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

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

Answer 9

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

Единственное место, где я нашел удобные настройки по умолчанию, было для простой схемы «Аудит». В каждой таблице было четыре столбца: InsertedAt, InsertedBy, updatedAt, updatedBy с ограничением, не равным NULL. Использовал триггер после для установки значений, но SQL Server проверил бы, чтобы столбцы имели значения. Если не произошло ограничение, оно так и не дошло до триггера. Поэтому я добавил значения по умолчанию, потому что эти значения не должны были устанавливаться кодом, выполняющим вставку. По умолчанию были полночь 1 января 1900 года и несуществующий пользователь. Триггер проверит, что значения соответствуют значениям по умолчанию, и выдаст ошибку, если кто-нибудь попытается установить значения во время вставки. (Кроме того, обновление выдало ошибку, если кто-то пытался обновить столбцы аудита.)

Answer 10

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