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

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

Этот столбец никогда не обновляется хранимыми процедурами или бизнес-логикой, но обновляется автоматически триггерами при изменении любого значения в строке. Однако по умолчанию также установлено значение 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

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

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

Обычно я просто использую таблицу базы данных в качестве очереди - веб-приложение вставляет строки для каждого сообщения, которое оно хочет отправить. Приложение службы/запланированной задачи извлекает новые сообщения из таблицы и отправляет их. Это дает вам большую гибкость, если вы хотите переключить почтовые серверы позже, лучшую надежность, если почтовый сервер не работает, более простую диагностику, если есть проблемы с получателями, не получающими сообщения, и возможность повторной отправки сообщений. Что касается использования JMS/MQ для этого - вероятно, нет необходимости. IMO таблица базы данных, используемая в качестве очереди, даст вам больше гибкости, чем фактическая система очередей на основе JMS.

Что касается выбора, ДА - вы должны дать людям способ отказаться. Я не думаю, что вам нужно помечать сообщения как массовые.

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

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

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

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

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

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

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

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

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

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

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

Один практический случай, в котором я лично нашел хорошее применение значениям по умолчанию - это столбец 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

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

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

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

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

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

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

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