Tengo una base de datos que no está en producción, por lo que la tabla principal es CustodyDetails, esta tabla tiene una ID int IDENTITY(1,1) PRIMARY KEY
columna y estoy buscando una forma de agregar otro identificador único al que no se haga referencia en ninguna otra tabla, creo que tomando esto en cuenta que el contenido de la columna no sería exactamente una clave de identidad.
Sin embargo, esta nueva columna de identidad tiene algunos detalles específicos, y aquí es donde comienza mi problema. El formato es el siguiente: XX/YY
donde XX es un valor auto incrementable que se reinicia / reinicia cada año nuevo e YY son los últimos 2 dígitos del año actual SELECT RIGHT(YEAR(GETDATE()), 2)
.
Entonces, por ejemplo, supongamos que se agrega un registro al día a partir del 28/12/2015 y finaliza el 01/03/2016 , la columna se vería así:
ID ID2 DATE_ADDED
1 1/15 2015-12-28
2 2/15 2015-12-29
3 3/15 2015-12-30
4 4/15 2015-12-31
5 1/16 2016-01-01
6 2/16 2016-01-02
7 3/16 2016-01-03
Pensé en usar la interfaz para analizar la ID compuesta (ID2 en el ejemplo), obtener los últimos 2 dígitos y compararlos con los últimos 2 dígitos del año actual y luego decidir si iniciar o no un nuevo correlativo. Por supuesto, sería grandioso poder hacerlo todo en el lado de la base de datos.
EDITAR 1: por cierto, también he visto personas que usan tablas separadas solo para almacenar claves de identidad paralelas, por lo que una clave de identidad de tabla se convierte en una segunda clave secundaria de tabla, esto suena un poco dudoso, pero tal vez este sea el caso de que dicha implementación se implemente.
EDITAR 2: Esta identificación adicional es una referencia de documento heredado que etiqueta cada archivo / registro. Supongo que uno podría pensarlo como un alias especial para la ID principal.
La cantidad de registros que maneja esta base de datos anualmente no ha estado fuera de los 100 en los últimos 20 años y es altamente (muy, muy altamente) improbable de lo que sería, por supuesto, si supera los 99, el campo podrá continúe con el dígito adicional y el frontend / procedimiento podrá superar los 99, por lo que no parece que cambie las cosas.
Por supuesto, algunos de estos detalles que no mencioné al principio porque solo reducirían las posibilidades de solución para satisfacer mi necesidad específica, trataron de mantener el rango del problema más amplio.
ID
= 5, 6 y 7, el DATE_ADDED debería ser 2016-01-01
y así sucesivamente.