O tamanho de dateTime2 (0), dateTime2 (1), dateTime2 (2), dateTime2 (3) usa a mesma quantidade de armazenamento. (6 bytes)
Eu estaria correto ao dizer que também poderia usar dateTime2 (3) e obter o benefício da precisão sem custos adicionais de tamanho.
Não, você interpretou mal a documentação. Observe que o documento indica o tamanho do armazenamento de 6 bytes para precisões menores que 3 (ênfase minha). Portanto, uma precisão igual a 3 exigirá 7 bytes.
Se você não se importa com milissegundos, datetime2(0)seria o tipo de dados e a precisão adequados. A melhor prática é especificar o tipo de dados e a precisão adequados, com base nos dados armazenados, pois isso inerentemente fornecerá armazenamento e eficiência ideais. Dito isto, eu não esperaria um impacto significativo no desempenho com base na precisão especificada datetime2, desde que o tamanho do armazenamento seja o mesmo, mas eu mesmo não o testei especificamente.
Os requisitos do aplicativo determinam o que deve ser armazenado no banco de dados quando uma maior precisão estiver disponível na fonte. Por exemplo, para um horário de entrada do pedido originado SYSDATETIME(), os usuários podem não querer precisão de 100 nanossegundos. Mais uma vez, escolha o tipo de dados e a precisão para o novo desenvolvimento, de acordo com os requisitos e, em geral, você obterá o desempenho ideal sem pensar mais:
- data - você não precisa de tempo
- smalldatetime - você não precisa de segundos
- datetime2 (0) - você não precisa de segundos fracionários
- datetime2 (1-7) - você precisa de segundos fracionários da precisão especificada
- datetimeoffset (0-7) - você precisa de data e hora com reconhecimento de fuso horário
- time (0-7) - você só precisa de tempo (sem data) com segundos fracionários da precisão especificada
Embora datetime2 seja mais apropriado para o novo desenvolvimento, conforme listado acima, às vezes pode ser necessário usar datetime (precisão fixa 3 com precisão de 1/300 segundos fracionários) para compatibilidade com aplicativos de datetime herdados, evitando conversões implícitas e comportamento inesperado de comparação, mas em a despesa da segunda precisão fracionária e maior armazenamento.
Considere que armazenar uma precisão maior do que o necessário também pode ter um custo de desenvolvimento. Se alguém armazenar um componente de tempo com segundos fracionários, quando apenas uma precisão de segundo inteiro for necessária, as consultas ainda precisarão considerar os segundos fracionários para retornar os resultados corretos. Por exemplo, com um aplicativo em que o usuário seleciona um intervalo de tempo por meio de uma interface do usuário que permite apenas segundos inteiros, o código do aplicativo precisaria contabilizar os segundos fracionários no valor do intervalo de tempo final e ajustar o valor fornecido pelo usuário de acordo com isso (por exemplo, WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99'ou WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00') Isso adicionará complexidade ao código.