Значение по умолчанию в дизайне базы данных sql

Question

Всегда ли полезно указывать значения по умолчанию для целочисленных полей? Я использую linq для доступа к базе данных.

Answer 1

Вы должны предоставлять значения по умолчанию только тогда, когда это имеет смысл, т.е.когда поле должно иметь определенное значение, если вы не укажете явно другое.Например, поле «Дата создания» должно иметь значение по умолчанию GetDate (), а поле «Дата рождения» не должно иметь значения по умолчанию.Лучше сделать поле NULLable и установить его в NULL, чем использовать значение по умолчанию, которое не имеет смысла.

Тип поля не имеет значения при выборе значения по умолчанию.

Answer 2

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

Answer 3

Я предполагаю, что вы используете linq-to-sql (хотя вопрос помечен только linq).

Я бы определенно рекомендовал не использовать значения по умолчанию в БД. Слой linq-to-sql (по крайней мере, если он генерируется с помощью sqlmetal, я предполагаю, что он одинаков для конструктора) не будет использовать значения по умолчанию из базы данных, а скорее значение по умолчанию для типа C # - что означает 0 для числовых типов. В этом случае наличие значений по умолчанию, которые не соблюдаются в коде, вызовет путаницу.

Answer 4

Это хорошая идея, если эти поля имеют тип, который ДОЛЖЕН иметь какое-то значение, и где значение по умолчанию имеет смысл. Например, поле с именем personAge может не иметь смысла иметь значение по умолчанию (можете ли вы разумно предположить, что все ваши записи person будут иметь одинаковый возраст, если не указано иное?). Возможно, было бы лучше, чтобы он был обнуляемым, а затем обрабатывать ошибки, когда появляются отсутствующие данные.

Answer 5

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

Использование значений по умолчанию, чтобы избежать появления нулей там, где они подходят, на мой взгляд, очень плохая практика. В частности, установка целого числа в значение по умолчанию, равное 0, если вы не знаете, каким оно должно быть, глупо и недальновидно, поскольку могут быть фактические значения 0. Нуль означает неизвестность, и если нельзя ожидать, что данные будут известны во время ввода данных, очень плохая практика - делать столбец необнуляемым и устанавливать значение по умолчанию, особенно для целых чисел и дат. Теперь вы не знаете, является ли значение действительно нулевым или только заполнителем, пока не узнаете значение. Теперь вам нужно написать специальные правила для поддельных значений (особенно если вы подставили поддельное значение для даты типа «19000101»). Никогда не используйте значения по умолчанию в базе данных только для того, чтобы избежать обнуляемых столбцов.