Должна ли таблица базы данных иметь значения по умолчанию?

Question

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

Answer 1

Мое правило: если многие записи будут использовать это значение по умолчанию (по крайней мере, на начальном этапе), то я хотел бы использовать его по умолчанию. Например, таблица изображений для продуктов в интернет-магазине может иметь путь по умолчанию images/NoPictureYet.png. В конце концов, они будут заменены, но для пакетных загрузок данных, когда картинки просто еще не существуют (и, возможно, большинство из них никогда не будет!), Значение по умолчанию имеет смысл (по крайней мере для меня).

Если нет разумного значения по умолчанию (такого как «имя» в базе данных клиентов - я не хочу, чтобы МОЕ имя по умолчанию было «FirstName»), тогда я делаю его ненулевым и не используемым по умолчанию - это ответственность приложения чтобы убедиться, что введено правильное значение.

Но никаких жестких и быстрых правил на этот счет. Все немного меняется;)

Answer 2

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

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

ALTER TABLE users ADD CONSTRAINT dc_users_last_modified
                  DEFAULT GETDATE()
                  FOR last_modified;

Триггер обновления будет выглядеть примерно так:

CREATE TRIGGER trigUpdate_users 
ON users 
FOR UPDATE 
AS 
BEGIN 
    IF NOT UPDATE(last_modified) 
        UPDATE users SET last_modified = GETDATE() 
        WHERE user_id IN (SELECT user_id FROM inserted);
END 
GO

Answer 3

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

Answer 4

tl; dr: Значения по умолчанию - бизнес-логика, и я хочу бизнес-логику в объектной модели. Таким образом, база данных не может содержать значения по умолчанию.

например. В базе данных у меня есть битовое поле: IsANicePerson. Это поле переводится в свойство класса Person. Будучи оптимистом по натуре, я хочу, чтобы значение по умолчанию для этого свойства было 'true'. Поэтому в классе Person я реализую это (как значение по умолчанию для вспомогательного поля isANicePerson). Если бы я позволил значения по умолчанию в базе данных, мне пришлось бы дублировать эту логику. Дублированный код / ​​логика - это плохо. Отсюда мое возражение против значений по умолчанию.

Отказ от ответственности: я живу в ОО-мире и использую Linq2Sql.

Answer 5

Значения по умолчанию важны, если столбец должен иметь значение (не ноль).Фактически, если вы изменяете столбец с разрешения на пустые значения на недопустимые, значение по умолчанию очень необходимо, поскольку не весь существующий код может заполнять значение.Иногда в этом случае значением по умолчанию является что-то вроде «НЕИЗВЕСТНО».Это особенно верно, если вы хотите использовать WITH VALUES для предоставления значений по умолчанию для существующих записей, где поле имеет значение null в операторе ALTER TABLE, который изменяет столбец на NOT NULL

Значения по умолчанию являются критическими для полей, которыепользовательский интерфейс обычно не имеет дело с.Например, у нас есть значения по умолчанию для столбцов date_inserted и user_inserted, о которых пользователь даже не подозревает.Это особенно важно, если многие разные приложения могут заполнять данные, чтобы никто не забыл об этих столбцах.

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

Хотя многие столбцы не могут иметь значения по умолчанию.Каким будет адрес или имя пользователя по умолчанию?

Answer 6

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

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

Answer 7

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

Answer 8

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

1) Столбцы CreatedDate и ModifiedDate. Эти столбцы обычно имеют getdate () (сервер sql), определенный по умолчанию. Как упоминалось в других сообщениях, эти поля могут быть обновлены с помощью триггеров и т. Д.

2) Булевы столбцы состояния. Примеры: «IsDefault», «IsDeleted» (для аудита), «IsActive» и т. Все эти поля обычно имеют логическое состояние по умолчанию, которое должно определяться моделью данных. Исключениями из этого, очевидно, будут логические поля с тремя состояниями, в которых можно принимать значения NULL, где нулевое состояние представляет что-то для данных, хранящихся в записи.

3) Определения ограничений данных: столбцы с AllowNull = false и по умолчанию не определены. Другими словами, значение требуется приложением.

4) Идентификационные данные внешнего ключа таблицы поиска: вероятно, это не норма, но для многих внешних ключей таблицы поиска я определю значение по умолчанию, которое охватывает начальное состояние записи. Так, например, в таблице «Event» столбец внешнего ключа «EventTypeId» (int-autoincrement) будет иметь значение по умолчанию 1 и представлять «General» или что-то в этом роде. Это будет охватывать большинство сценариев, в которых, например, я хочу записать событие, но не обращаю внимания на конкретный идентификатор типа.

5) Некритические строковые столбцы: «Описание», «Комментарий» и т. Д. Для этих столбцов я обычно определяю «» по умолчанию просто для упрощения System.DbNull => Обработка нулевого преобразования в приложениях. Это может быть неприменимо во всех сценариях, особенно когда соответствующая таблица содержит миллионы строк, а место для хранения является проблемой.

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

Answer 9

Определенно серая зона. Это классика, сколько бизнес-логики поставить в вопросе базы данных.

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

Практически мы можем сделать исключение, как мы часто это делаем, и разрешить логику дефолта в базе данных.