SQL DataType - ¿Cómo almacenar un año?

Regular 4 byte INT es camino a grande, es una pérdida de espacio!

No dice qué base de datos está utilizando, por lo que no puedo recomendar un tipo de datos específico. Todo el mundo está diciendo "usar entero", pero la mayoría de las bases de datos almacenan enteros a 4 bytes, que es mucho más de lo que necesita. Debe usar un entero de dos bytes (smallint en SQL Server), que conservará mejor el espacio.

Hey, puedes Usar year () datatype en MySQL Está disponible en formato de dos o cuatro dígitos.

Nota: Valores permitidos en formato de cuatro dígitos: 1901 a 2155. Valores permitidos en formato de dos dígitos: 70 a 69, que representan los años de 1970 a 2069

Almacenar un "Año" en MSSQL idealmente dependería de lo que esté haciendo con él y cuál sería el significado de ese "año" para su aplicación y base de datos. Dicho esto, hay algunas cosas que declarar aquí. No hay "Tipo de datos" para el año a partir de 2012 en MSSQL. Me inclinaría hacia el uso de SMALLINT ya que es solo 2 bytes (ahorrándole 2 de los 4 bytes que demanda INT). Su limitación es que no puede tener un año más antiguo que 32767 (a partir de SQL Server 2008R2). Realmente no creo SQL será la base de datos de elección dentro de diez mil años y mucho menos 32767. Puede considerar INT como la función Year () en MSSQL convierte el tipo de datos "DATE" a un INT. Como he dicho, depende de dónde está obteniendo los datos y hacia dónde va, pero SMALLINT debería estar bien. INT sería exagerado ... a menos que tenga otras razones como la que mencioné anteriormente o si los requisitos del código lo necesitan en forma INT (por ejemplo, integración con la aplicación existente). Muy probablemente SMALLINT debería estar bien.

Sólo un año, ¿nada más ? ¿Por qué no usar un entero simple ?

Use integer si todo lo que necesita almacenar es el año. También puede usar datetime si cree que habrá cálculos basados en fechas mientras consulta esta columna

El almacenamiento puede ser solo una parte del problema. ¿Cómo se utilizará este valor en una consulta?

¿Se va a comparar con otros tipos de datos de fecha y hora, o todas las filas asociadas también tendrán valores numéricos?

¿Cómo manejaría un cambio en los requisitos? ¿Qué tan fácilmente podría reaccionar a una solicitud para reemplazar el año con un segmento de tiempo más pequeño? es decir, ¿ahora lo quieren desglosado por monedas?

Un tipo numérico se puede usar fácilmente en una consulta de fecha y hora tabla de búsqueda con la que unirse que contiene cosas como las fechas de inicio y parada (1/1/X a 12/31/x), etc..