Должен ли таблица базы данных иметь значения по умолчанию?
https://stackoverflow.com/questions/2284621
-
21-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
У меня была обсуждение с разработчиком, работающим над вопросом, если таблица использует значения по умолчанию. Есть ли жесткое и быстрое правило в этом или это серая область в лучших практиках?
Решение
Мое правило: если многие записи будут использовать это значение по умолчанию (по крайней мере, изначально), мне нравится использовать его в качестве дефолта. Например, таблица изображений для продуктов в интернет -магазине может иметь путь по умолчанию images/NoPictureYet.png. Анкет В конце концов, они будут заменены, но для партийных данных данных, где изображений еще не существует (и, возможно, большинство из них никогда не будут!), По умолчанию имеет смысл (по крайней мере, для меня).
Если нет разумного по умолчанию (например, «Имя» в базе данных клиентов - я не хочу, чтобы мое имя не выполнило «FirstName»), то я делаю его не нулевым и не является дефолтом - это обязанность приложения для обеспечения того, чтобы Правильное значение вводится.
Но никаких жестких и быстрых правил в этом. Все это немного меняется;)
Другие советы
Один практический случай, когда я лично нашел хорошее использование значений по умолчанию, - это для 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
Не может быть применено жесткое и быстрое правило. Это зависит от столбцов. Например, может быть совершенно разумно иметь тип заказа по умолчанию, но идея по умолчанию для номера телефона клиента не имеет смысла.
Я бы сказал, что это серая область. Как правило, я бы не разработал новую базу данных с большим количеством значений по умолчанию, но вам часто нужно использовать их при улучшении существующей системы.
Например, добавление нового не нулевого столбца в существующую базу данных. Вы можете не захотеть (или иметь возможность) обновлять весь код, который вставляется в эту таблицу, поэтому вам нужно будет нанести по умолчанию, чтобы гарантировать, что любой «устаревший» код может все еще вставить данные (при условии, что значение по умолчанию подходит для устаревшего кода, конечно).
Значения по умолчанию важны, если столбец должен иметь значение (он не нулевой). Фактически, если вы меняете столбец с разрешения Nulls не разрешать им значение по умолчанию в значительной степени необходимо, поскольку не весь существующий код может заполнить значение. Иногда в этом случае значение по умолчанию - что -то вроде «неизвестного». Это особенно верно, если вы хотите использовать значения с значениями, чтобы предоставить значения по умолчанию для оборудования записей, в которых поле является нулевым в операторе ALTER TABLE, который изменяет столбец на NOT NULL
Значения по умолчанию имеют решающее значение для полей, с которыми обычно не имеет дело пользовательского интерфейса. Например, у нас есть значения по умолчанию в столбцах date_inserted и user_inserted, которые пользователь даже не знает. Это особенно важно, если многие различные приложения могут заполнить данные, чтобы никто не забыл об этих столбцах.
Тогда есть столбцы, которые обычно дают значение при вводе данных, которое может измениться позже. Такие вещи, как столбец статуса.
Многие столбцы не могут иметь по умолчанию. Каким будет адрес по умолчанию или имя пользователя?
TL; DR: Значения по умолчанию - бизнес -логика, и я хочу бизнес -логику в объектной модели. Таким образом, база данных не может содержать значения по умолчанию.
Например, в базе данных у меня есть немного поля: Исанисперан. Это поле переводится на собственность в классе человека. Будучи оптимистичным по своей природе, я хочу, чтобы значение по умолчанию было «истинным». Таким образом, в классе человека я реализую это (как значение по умолчанию поля поддержки Исанисперса). Если бы я разрешил бы значения по умолчанию в базе данных, мне придется дублировать эту логику. Дубликат код/логика плохая. Отсюда я возражает против значений по умолчанию.
Отказ от ответственности: я живу в мире OO и использую linq2sql.
Это должно быть довольно просто. Если данные, как правило, являются уникальными для каждой строки, например, номер телефона клиента или значение по умолчанию, скорее всего, со временем изменятся, я бы не использовал его. Это означает, что это на самом деле полезно только для заполнения создания, модифицированных или других столбцов такого рода.
Вот рекомендации, которые я лично использую в отношении значений по умолчанию, которые хорошо послужили мне в прошлом. В следующих примерах рассмотрите бэкэнд базы данных с несколькими приложениями с доступом к чтению/записи к бэкэнд. В этих случаях важно, чтобы база данных определила, как должны быть смоделированы данные, и, следовательно, обеспечивали целостность данных.
1) Созданные и модифицированные столбцы. Эти столбцы, как правило, будут иметь getDate () (SQL Server), определяемый как по умолчанию. Как упомянуто в других сообщениях, эти поля могут быть обновлены с помощью триггеров и т. Д.
2) Булевые столбцы. Примеры: «IsDefault», «Isdeleted» (для аудита), «Isactive» и т. Д. Все эти поля, как правило, будут иметь логическое состояние по умолчанию, которое должно определяться моделью данных. Исключения из этого, очевидно, были бы нулевыми логическими полями, где нулевое состояние представляет что-то о данных, хранящихся в записи.
3) Определения ограничений данных: столбцы с Allownull = false и не определены по умолчанию. Другими словами, приложение требуется значение.
4) Поиск таблицы иностранных ключей: это, вероятно, не норма, а для многочисленных таблиц поиска иностранных ключей я определяю дефолт, который охватывает начальное состояние записи. Так, например, в таблице «Событие» столбец иностранного ключа «EventTyPeid» (Int-Autoincrement) будет иметь дефолт 1 и представлять «общий» или что-то в этом роде. Это будет охватывать большинство сценариев, где, например, я хочу войти в систему события, но не заботится о конкретном идентификаторе типа.
5) Некритические строковые столбцы: «Описание», «Комментарий» и т. Д. Для этих столбцов я обычно определяю «как по умолчанию исключительно для обмена систем. Это то, что может быть не применимо во всех сценариях, особенно когда соответствующая таблица содержит миллионы рядов, и пространство для хранения является проблемой.
Таким образом, используйте значения по умолчанию, чтобы обеспечить целостность данных фактических данных, хранящихся в базе данных. Модель данных должна определить эти правила целостности данных внутри себя, и любое взаимодействие с ней приложением будет и должно быть вынуждено уважать эти правила. Также обратите внимание, что это не доктрина и что всегда будут исключения. Рассмотрим каждый сценарий индивидуально, чтобы он имел смысл для вашей базы данных/приложения.
Определенно серая область. Это классика, сколько бизнес -логики на вопрос о базе данных.
Если мы хотим быть пуристом и сказать, что ни одна бизнес -логика не принадлежит к базе данных, то ответ никогда не будет их использовать.
Будучи практичными, мы можем сделать исключение, как мы часто делаем, и разрешить логику по умолчанию в базу данных.
