El tamaño de dateTime2 (0), dateTime2 (1), dateTime2 (2), dateTime2 (3) usa la misma cantidad de almacenamiento. (6 bytes)
¿Sería correcto decir que también podría usar dateTime2 (3) y obtener el beneficio de la precisión sin ningún costo de tamaño adicional.
No, malinterpretaste la documentación. Tenga en cuenta que el documento indica un tamaño de almacenamiento de 6 bytes para precisiones inferiores a 3 (énfasis mío). Entonces, una precisión igual a 3 requerirá 7 bytes.
Si no le importan los milisegundos, datetime2(0)sería el tipo de datos y la precisión adecuados. La mejor práctica es especificar el tipo de datos y la precisión adecuados en función de los datos almacenados, ya que esto proporcionará inherentemente un almacenamiento y una eficiencia óptimos. Dicho esto, no esperaría un impacto significativo en el rendimiento basado en la precisión de datetime2 especificada, siempre que el tamaño de almacenamiento sea el mismo, pero no lo he probado específicamente.
Los requisitos de la aplicación determinarán qué debe almacenarse en la base de datos cuando haya una mayor precisión disponible en la fuente. Por ejemplo, para un tiempo de entrada de pedido procedente de SYSDATETIME(), los usuarios pueden no querer una precisión de 100 nanosegundos. Nuevamente, elija el tipo de datos y la precisión para el nuevo desarrollo de acuerdo con los requisitos y generalmente obtendrá un rendimiento óptimo sin pensarlo más:
Aunque datetime2 es el más apropiado para un nuevo desarrollo como se menciona anteriormente, a veces es necesario usar datetime (precisión fija 3 con precisión de 1/300 segundos fraccionales) en lugar de compatibilidad con aplicaciones heredadas de fecha y hora, evitando así conversiones implícitas y comportamientos de comparación inesperados, pero en el gasto de una precisión fraccional de segundo y un mayor almacenamiento.
Tenga en cuenta que almacenar una precisión mayor que la requerida también puede tener un costo de desarrollo. Si se almacena un componente de tiempo con segundos fraccionarios cuando solo se requiere precisión de un segundo entero, las consultas aún deberán considerar los segundos fraccionarios para devolver los resultados correctos. Por ejemplo, con una aplicación en la que el usuario selecciona un rango de tiempo a través de una interfaz de usuario que solo permite segundos completos, el código de la aplicación debería tener en cuenta los segundos fraccionarios en el valor del rango de tiempo final y ajustar el valor proporcionado por el usuario en consecuencia (p. Ej. WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99'o WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00') Esto agregará complejidad al código.