El Versionado (Fecha Desde y Fecha Hasta) y otras Fechas relacionadas (Fecha Alta, Fecha Baja, Fecha Creación o Timestamp, etc.)

Los campos Fecha Desde y Fecha Hasta no tienen por qué ser los únicos campos de tipo Fecha en nuestras tablas. De hecho, podemos encontrarnos con bastante frecuencia otros campos de tipo Fecha también relacionados con el Versionado (Fecha Desde y Fecha Hasta) de tablas. A continuación se explican algunos de estos campos Fecha auxiliares a los propios del versionado (Fecha Desde y Fecha Hasta):

• Fecha Hora de Creación (Timestamp). Un campo que almacene la Fecha Hora de Creación de un registro en la tabla, ofrece varias ventajas. Por ejemplo, si deseamos crear un índice único, podríamos generarlo utilizando la composición de la Clave de Negocio (Business Key) y la Fecha Hora de Creación (Timestamp) del registro. Del mismo modo, con fines de auditoría, nos permitiría conocer el momento en el tiempo exacto de la creación del registro, ya que Fecha Desde (en el Modelo de Versionado propuesto en este Artículo) sólo almacena la Fecha, sin la información horaria, lo cual resulta impreciso. Además, Fecha Desde podría no ser representativo de la Fecha Hora de Creación, ya que en determinados casos puede ser interesante crear un registro con Fecha Desde anterior a la Fecha Actual para conseguir un efecto retroactivo o eventualmente para corregir datos (igualmente que podría ser interesante crear Fecha Desde posterior a la Fecha Actual).
• Fecha Hora de Actualización. Un campo que almacene la Fecha Hora de Actualización de un registro en la tabla, puede resultar de utilidad para aquellos cambios que no generen una nueva versión, de tal modo, que junto a la Fecha Hora de Creación, podamos conocer si en una determinada Versión se han producido cambios desde su creación (es decir, si la Fecha Hora de Actualización es mayor que la Fecha Hora de Creación).
• Fecha Alta y Fecha Baja. Los campos Fecha Alta y Fecha Baja permiten definir para una versión determinada, el periodo de vigencia de la misma. Son de gran utilidad, ya que en la mayoría de los casos, se toma como premisa que NO se eliminan los datos de las tablas, en su lugar se establece la Fecha de Baja .Tomando el ejemplo de una tabla de Usuarios, podría darse el caso de:
  
  
  • Crear un Usuario el día 01/01/2008, con Fecha Desde = 01/01/2008, Fecha Alta = 01/01/2008, Fecha Hasta = 31/12/9999 y Fecha Baja = 31/12/9999.
  • Posteriormente, el día 01/06/2008 se decide dar de baja el usuario. Por ello, se actualiza la versión actual con Fecha Hasta = 01/06/2008, y se genera una nueva versión Fecha Desde = 01/06/2008, Fecha Alta = 01/01/2008, Fecha Hasta = 31/12/9999 y Fecha Baja = 01/06/2008.
  
  Este comportamiento es muy versátil, ya que funcionalmente permite muchas posibilidades. Por ejemplo, ¿Y si se necesita volver a dar de alta al mismo usuario el 01/09/2008? Pues muy fácil, tan sólo es necesario actualizar la versión actual con Fecha Hasta = 01/09/2008, y generar una nueva versión Fecha Desde = 01/09/2008, Fecha Alta = 01/09/2008, Fecha Hasta = 31/12/9999 y Fecha Baja = 31/12/9999.
  
  Es muy interesante el detalle de que en ningún momento se pierde información. En el ejemplo descrito, comprobando las diferentes versiones, podríamos ver claramente que desde el 01/06/2008 al 01/09/2008 el usuario ha estado dado de baja.
  
  Además, también sería posible dar de alta un Usuario con Fecha Alta posterior a Fecha Desde, por ejemplo, si estamos realizando una carga masiva de usuarios el día 01/01/2008, pero deseamos que no puedan conectarse hasta el día 01/02/2008 (es decir, Fecha Desde = 01/01/2008 y Fecha Alta = 01/02/2008).

Como consecuencia de todo esto, resulta especialmente importante (al menos en muchos casos), además de utilizar los campos Fecha Desde y Fecha Hasta, también incluir Fecha de Creación, Fecha Alta y Fecha Baja. Eso sí, los campos Fecha Desde y Fecha Hasta serán gestionados internamente por las propias aplicaciones (el usuario no los podrá modificar directamente) mientras que los campos Fecha Alta y Fecha Baja serán rellenados por los usuarios (habitualmente, quiero decir). También es interesante recordar, que en ocasiones las aplicaciones gestionan de forma interna otros campos. Por ejemplo, en algunas aplicaciones se almacena en todas las tablas un campo con el último usuario que modificó (o creo) cada fila.

Vaya... en el capítulo anterior parecía que habíamos visto todo sobre el comportamiento de tablas versionadas (Fecha Desde y Fecha Hasta), y ahora resulta que acabamos de complicar más nuestro Modelo de Versionado: no sólo debemos gestionar nuestras Fecha Desde y Fecha Hasta, sino que además deberemos gestionar correctamente nuestras Fecha Alta, Fecha Baja y Fecha Hora de Creación.

Bueno... tranquisú.... poco a poco, y paso a paso...