Минимальное время ожидания TSQL по умолчанию

Ответ 1

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

Попытка сделать из значений, таких как 0, чтобы получить минимальную дату, будет по умолчанию равна 01-01-1900.

Как было предложено ранее, лучше всего оставить значение NULL (и использовать ISNULL при чтении, если вам нужно), или если вы обеспокоены его правильной настройкой, вы даже можете установить триггер в таблице, чтобы установить измененную дату на изменения.

Если у вас настроено ваше сердце на получение минимально возможной даты, выполните следующие действия:

create table atable
(
  atableID int IDENTITY(1, 1) PRIMARY KEY CLUSTERED,
  Modified datetime DEFAULT '1753-01-01'
)

Ответ 2

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

Существует плата за установку столбцов с нулевым значением: NULL не индексируются. Такой запрос, как "получить все записи, которые не были изменены с начала 2010 года", включает те, которые никогда не были изменены. Если мы используем нулевой столбец, мы вынуждены использовать [modified] < @cutoffDate ИЛИ [изменено] ИМЕЕТ NULL, а это, в свою очередь, заставляет механизм базы данных выполнять сканирование таблицы, поскольку нули не индексируются. И это последнее может быть проблемой.

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

Короче говоря, по глупости/эмпирическому правилу нужно идти за NULL. Но если имеется огромное количество записей, данные часто запрашиваются, и только небольшая часть записей имеет значение NULL/special, может быть значительное увеличение производительности для поиска записей на основе этой информации (при условии, что, конечно, создается index!) и ИМХО это время от времени оправдывает использование "магических" значений.

Ответ 3

"Возможно, я должен оставить его нулевым"

Не используйте магические числа - это плохая практика - если у вас нет значения, оставьте его null

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

Ответ 4

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

Modified datetime DEFAULT ((0)) 

абсолютно безопасен и звучит и позволяет более элегантные запросы, чем "1753-01-01", и более эффективные запросы, чем NULL.

Однако, поскольку первый Модифицированный datetime - это время, в которое была вставлена ​​запись, вы можете использовать:

Modified datetime NOT NULL DEFAULT (GETUTCDATE())

что позволяет избежать всей проблемы и упрощает и упрощает ваши вставки - так как вы не вставляете ее вообще, а SQL выполняет домашнюю работу:-)

Благодаря этому вы все еще можете иметь изящные и быстрые запросы, используя 0 как практический минимум, поскольку он гарантированно всегда будет ниже, чем любой созданный вставки GETUTCDATE().

Ответ 5

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

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

-- CREATE FUNCTION
CREATE FUNCTION dbo.DateTime_MinValue ( )
RETURNS DATETIME
AS 
    BEGIN
        DECLARE @dateTime_min DATETIME ;
        SET @dateTime_min = '1/1/1753 12:00:00 AM'
        RETURN @dateTime_min ;
    END ;
GO


-- CREATE TABLE USING FUNCTION FOR DEFAULT
CREATE TABLE TestTable
(
  TestTableId INT IDENTITY(1, 1)
                  PRIMARY KEY CLUSTERED ,
  Value VARCHAR(50) ,
  Modified DATETIME DEFAULT dbo.DateTime_MinValue()
) ;


-- INSERT VALUE INTO TABLE
INSERT  INTO TestTable
        ( Value )
VALUES  ( 'Value' ) ;


-- SELECT FROM TABLE
SELECT  TestTableId ,
        VALUE ,
        Modified
FROM    TestTable ;


-- CLEANUP YOUR DB
DROP TABLE TestTable ;
DROP FUNCTION dbo.DateTime_MinValue ;

Ответ 6

Я думаю, что это сработает...

create table atable
(
  atableID int IDENTITY(1, 1) PRIMARY KEY CLUSTERED,
  Modified datetime DEFAULT ((0))
)

Изменить: это неправильно... Минимальное значение DateTime для SQL равно 1/1/1753. Мое решение предоставляет дату и время = 1/1/1900 00:00:00. Другие ответы имеют правильную минимальную дату...

Ответ 7

Я думаю, что ваш единственный вариант здесь - постоянный. С учетом сказанного - не используйте его - придерживайтесь нулей вместо фиктивных дат.

create table atable
(
  atableID int IDENTITY(1, 1) PRIMARY KEY CLUSTERED,
  Modified datetime DEFAULT '1/1/1753'
)