Если этот вопрос слишком широк, мои извинения. Я - администратор базы данных, и я работаю с разработчиком, который считает, что значения столбцов по умолчанию - это плохая идея, и достаточно просто установить столбец для отказа от нулей.Каковы преимущества установки значения по умолчанию в столбце?
Я ищу преимущества по умолчанию для столбцов с точки зрения разработчиков. Спасибо за ваши Коментарии.
Значения столбцов по умолчанию позволяют удалить много проблем с созданием записей из вашего кода или логики приложения.
Преимущество # 1: Если у вас есть таблица с 2 столбцами информации пользователя и 20 столбцов TinyInt/логических полей, скажем, они являются параметры конфиденциальности, и вы идете, чтобы создать новую запись в этой таблице, без значение DEFAULT, которое вам нужно будет указать каждый столбец в вашем запросе. Вероятно, есть общая настройка, которую вы хотите, чтобы эти записи имели по умолчанию, и вы можете установить ее с помощью значений DEFAULT. Когда вы записываете запись, вам нужно указать только два поля информации об пользователях, а волала, ваша запись создана с хорошим набором общих настроек конфиденциальности. После этого вы можете настроить флаги отдельно.
Преимущество # 2: Вперед совместимость! Если в вашем коде есть пучок INSERT s, а затем добавляются некоторые столбцы, вам нужно будет вернуться и изменить все эти INSERT с, если вы не указали значение DEFAULT (предполагая, что это обычно , что NULL s не собирается сокращать его).Часто нет необходимости обновлять старый код для нового столбца (поскольку старый код по своему характеру не заботится о новом столбце), так что это было бы огромными больми в @ $$, если бы вам пришлось начинать возвращаясь и обрабатывая каждый новый столбец вашего кода по мере его появления.
Значение по умолчанию значительно упрощает вставку новых строк в таблицу - все столбцы со значением по умолчанию не должны быть явно указаны и снабжены значением в инструкции INSERT, если это значение по умолчанию ОК (например getdate() для столбца даты «LastChangeOn»).
Я не вижу причин, по которым вы бы не использовали значения по умолчанию для столбца, действительно, при наличии допустимого и разумного значения по умолчанию. Я не понимаю, почему у вашего разработчика такое отвращение к значениям по умолчанию - их всегда можно переопределить в начальном INSERT (и после этого они больше не вступают в игру).
Marc
Конечно, вы имели в виду GetUtcDate() для LastChangeOn по умолчанию ... – IDisposable
Если вы имеете дело с приложениями, охватывающими несколько часовых поясов - да, определенно! –
Это зависит от ваших требований. Если ваши правила требуют минимального значения, а значение NULL не считается допустимым, тогда может потребоваться значение по умолчанию. Например, если у вас есть поля аудита, вам не понадобится нулевое значение в столбце CREATED_DATE. Однако, если у вас есть атрибут MIDDLE_NAME, вы должны разрешить NULLS, потому что не все имеют среднее имя. Опять же, это действительно зависит от ваших требований.
Но, пожалуйста, постарайтесь, чтобы значение CREATED_DATE по умолчанию не было более мелким, чем целые секунды (если только «первое, что было» * действительно * имеет значение). – RolandTumble
@ RolandTumble: Почему? –
Если вы добавляете столбец в существующую таблицу и не хотите, чтобы столбец был нулевым, вы должны указать значение по умолчанию.
Да, но по умолчанию можно удалить сразу после. Я все время это делаю. –
Многим разработчикам не нравится размещать бизнес-логику в базе данных. Разработчик может подумать, что он теряет контроль (он мог писать рутину, чтобы иметь собственный дефолт для чего-то другого, кроме нуля). Я не уверен, увидит ли он это, сделав ему одолжение или выполняя некоторые задания с его тарелки.
Я имею дело с базой данных, которая является бэкэнд сторонним приложением, и я ограничена тем, что мы можем делать с приложением (как и значения по умолчанию). Я не могу заставить приложение иметь значение по умолчанию во всех панелях ввода данных, поэтому я хотел бы поместить значение по умолчанию в поле в базе данных, где у меня есть контроль. У меня нет доступа к их коду, и наши пользователи не хотят ждать обновления.
Значения столбцов по умолчанию позволяют программисту быть ленивым. Это не обязательно плохо.
Разработчик делает очень хороший момент. Как правило, это хорошая идея быть настолько явной, насколько это возможно, а не полагаться на неявное поведение.
Я думаю, что он может быть прав. Если вы помещаете значения по умолчанию в столбцы, и код полагается на это, тогда изменение значения по умолчанию может привести к появлению ошибок, которые трудно устранить.
Обратное, однако, заключается в том, что установка значений по умолчанию в самой таблице данных позволяет изменить значение по умолчанию для столбца позднее, не перекомпилируя код. То есть, если человек, написавший код, перешел, думая достаточно, чтобы не переопределять значение по умолчанию, кроме случаев, когда это абсолютно необходимо.
Изменение значения по умолчанию для столбца имеет тенденцию редко случаться в моем опыте. Я могу вспомнить пару случаев за последние 10 лет или около того работы, которые я должен был сделать. Все они включали в себя большое обновление данных, чтобы идти вместе с ним, и код должен был быть обновлен в любом случае для учета новых ситуаций с данными. – zombat
Больше доказательств того, что, возможно, разработчик имеет правильную идею. – JohnFx
Это помогает при управлении версиями. Например, если старый код (операторы INSERT) ожидает таблицу с 10 столбцами, и этот старый код должен работать с новой таблицей с 12, тогда вам нужно указать значение по умолчанию для новых столбцов или сделать новые столбцы нулевыми ,
И это также зависит от точной семантики того, что означает NULL для данного столбца, поскольку выбор значений по умолчанию также является выбором для или против NULL в столбце. Означает ли пустой токен неизвестный, непознаваемый, еще не измененный, что-то в неизвестном прошлом, что-то в неизвестном будущем. Это немного разные токены, и NULL может означать только один из них.
Я думаю, что в зависимости от значений по умолчанию в БД полностью идет речь о защитном программировании, и вы смотрите на будущий кошмар.
В целом значения по умолчанию не вызываются. Если данные имеют некоторые значения по умолчанию, что имеет смысл, тогда идите и скопируйте их в базу данных. Но большинство данных не имеет значения по умолчанию. Каким будет значение по умолчанию для имени? Выбросьте значение null и позвольте коду присваивать значение. Не включайте значение по умолчанию, потому что вы хотите получить ошибку, если код забывает устанавливать имя, вместо того, чтобы иметь псевдоним по умолчанию.
Одно место, которое я нашел, по умолчанию было удобным для простой схемы «Аудит». В каждой таблице было четыре столбца: InsertedAt, InsertedBy, UpdAt, UpdateBy с неопределенным ограничением. Используется после триггера для установки значений, но SQL Server будет проверять, что столбцы имеют значения. Если не произошло нарушение ограничения, и он не дошел до триггера. Поэтому я добавил значения по умолчанию, потому что эти значения не были установлены с помощью кода, выполняющего вставку. По умолчанию они были полночь 1 января 1900 года и несуществующий пользователь. Триггер будет проверять, соответствуют ли значения по умолчанию и бросает ошибку, если кто-то попытался установить значения во время вставки. (Кроме того, обновление заставило ошибку, если кто-то попытался обновить столбцы аудита.)
Это зависит от ситуации. Существует множество ситуаций, когда значения по умолчанию помогают людям правильно получить данные. Формы ввода данных часто соответствуют шаблону. В форматах ввода данных значение по умолчанию может быть возвращено пользователю для проверки перед продолжением. Это часто позволяет пользователю переопределять значение по умолчанию, когда по умолчанию вздор.
Но интерфейс пользователя и интерфейс программиста - это разные вещи. Предоставление значения по умолчанию в БД часто является способом облегчения ввода информации об мусоре. Избавление от информации о мусоре, когда оно находится в БД, является трудоемким.
Итак ...Я бы установил значение по умолчанию, когда спецификация дизайна требует его. И в этом случае мнение разработчика должно сильно зависеть от дизайна.
Извините, что за вопрос, но если вы не можете придумать веские причины использовать значения по умолчанию для столбцов, то почему вы спорите с разработчиком об этом? – JohnFx
Он смотрит из POV разработчика; не его собственный. Может быть, у него много причин использовать дефолты и не может думать о каких-либо причинах не использовать их? – JeffO