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

Ответ 1

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

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

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

Ответ 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

Ответ 3

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

Ответ 4

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

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

Ответ 5

Значения по умолчанию важны, если столбец должен иметь значение (оно не равно нулю). Фактически, если вы меняете столбец, позволяя nulls не позволять им значение по умолчанию, в значительной степени необходимо, так как не все существующие коды могут заполнять значение. Иногда в этом случае значение по умолчанию - это что-то вроде "UNKNOWN". Это особенно актуально, если вы хотите использовать WITH VALUES для предоставления значений по умолчанию для записи записей, где поле имеет нулевое значение в инструкции ALTER TABLE, которая меняет столбец на NOT NULL

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

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

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

Ответ 6

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

Ответ 7

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

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

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

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

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

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

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

Ответ 8

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

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

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

Ответ 9

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

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

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