TSQL Default Minimum DateTime

Question

Al usar Transact SQL, ¿hay alguna forma de especificar un datetime predeterminado en una columna (en la declaración create table) para que datetime sea el valor mínimo posible para los valores de datetime?

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

Tal vez debería dejarlo nulo.

Answer 1

Por lo que yo sé, no existe ninguna función para devolver esto, tendrá que configurarlo con firmeza.

Intentar emitir desde valores como 0 para obtener una fecha mínima estará predeterminado a 01-01-1900.

Como lo mejor es dejarlo como NULL (y usar ISNULL cuando lo lea si lo necesita), o si le preocupa configurarlo correctamente, incluso podría establecer un disparador en la tabla para establecer su fecha de modificación en las ediciones.

Si usted tiene su corazón puesto en conseguir la fecha mínima posible, entonces:

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

Answer 2

"Quizás debería dejarlo nulo"

No utilice números mágicos - que es una mala práctica - si usted no tiene un valor nulo dejarlo

De lo contrario, si realmente quieres una fecha predeterminada - utilizar una de las otras técnicas enviado a fijar una fecha predeterminada

Answer 3

Creo que esto funcionaría ...

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

Editar: esto está mal ... El mínimo de SQL DateTi mi valor es 1/1/1753. Mi solución proporciona un datetime = 1/1/1900 00:00:00. Otras respuestas tienen la fecha mínima correcta ...

Answer 4

Creo que su única opción aquí es una constante. Dicho esto, no lo use, quédese con nulos en lugar de fechas falsas.

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

Answer 5

A menos que usted está haciendo una base de datos para rastrear los tiempos históricos más que hace un siglo, utilizando

Modified datetime DEFAULT ((0)) 

es perfectamente seguro y sonido y permite consultas más elegante que '1/1/1753' y consultas más eficientes que NULL.

Sin embargo, desde el primer Modificado datetime es el momento en que se insertó el registro, puede utilizar:

Modified datetime NOT NULL DEFAULT (GETUTCDATE()) 

que evita todo el tema y hace que sus inserciones más fácil y más seguro - como en el no lo hace insértela y SQL hace las tareas domésticas :-)

Con eso en su lugar todavía puede tener consultas elegantes y rápidas utilizando 0 como mínimo práctico, ya que se garantiza que siempre será menor que cualquier GETUTCDATE() generado por inserción.

Answer 6

Estoy de acuerdo con el sentimiento de "no usar valores mágicos". Pero me gustaría señalar que hay momentos en los que es legítimo recurrir a tales soluciones.

Hay un precio a pagar para establecer las columnas nulables: NULLs no son indexables.Una consulta como "obtener todos los registros que no se han modificado desde el inicio de 2010" incluye aquellos que nunca se han modificado. Si utilizamos una columna que admite nulos, nos vemos obligados a utilizar [modified] < @cutoffDate O [modificado] IS NULL, y esto a su vez obliga al motor de base de datos a realizar un examen de tabla, ya que los nulos no están indexados. Y este último puede ser un problema.

En la práctica, uno debería ir con NULL si esto no introduce una penalización práctica en el mundo real. Pero puede ser difícil de saber, a menos que tenga una idea de qué volúmenes de datos realistas son hoy y cuáles serán en el llamado futuro previsible. También necesita saber si habrá una gran proporción de los registros que tienen el valor especial; de ser así, no tiene sentido indexarlos de todos modos.

En resumen, por deafult/rule of thumb uno debe ir por NULL. Pero si hay una gran cantidad de registros, los datos se consultan con frecuencia, y solo una pequeña proporción de los registros tiene el valor NULO/especial, podría haber un aumento significativo en el rendimiento para localizar registros basados ​​en esta información (siempre que uno crea el index!) y en mi humilde opinión, esto a veces puede justificar el uso de valores "mágicos".

Answer 7

A veces heredas código frágil que ya está esperando valores de magia en muchos lugares. Todos son correctos, debes usar NULL si es posible. Sin embargo, como un atajo para asegurar que cada referencia a ese valor sea la misma, me gusta poner "constantes" (a falta de un nombre mejor) en SQL en una función de escalador y luego llamar a esa función cuando necesito el valor. De esa forma, si alguna vez quiero actualizarlos para que sean otra cosa, puedo hacerlo fácilmente. O si deseo cambiar el valor predeterminado para seguir adelante, solo tengo un lugar para actualizarlo.

El siguiente código crea la función y una tabla que lo usa para el valor predeterminado de DateTime. Luego inserta y selecciona de la tabla sin especificar el valor de Modificado. Luego se limpia después de sí mismo. Espero que esto ayude.

-- 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 ;