Modelo de datos

Voy a exponer un modelo de datos general para el diseño de bases de datos que a mi me resulta práctico a la hora de trabajar:

Estos serían los campos básicos de una tabla:

• id smallint(5) NOT NULL AUTO_INCREMENT
  Tener un identificador único para cada fila (se denomina Surrogate Key) tarde o temprano se agradece mucho más que tener que identificarlos mediante claves compuestas por varios campos. Además, como me gusta utilizar tablas versionadas o históricas (Slowly Changing Dimension de tipo 2), las Claves de Negocio (Business Key) pueden no tener un valor único en la tabla. Este concepto es muy utilizado en el diseño de bases de datos en entornos de Data Warehouse y Business Intelligence. En una tabla versionada SCD Tipo 2 es posible realizar un seguimiento de los cambios almacenando en cada fila, es decir, en cada versión, el periodo de tiempo para el cuál es válida la información de dicha fila (por ejemplo, incluyendo dos campos Fecha Desde y Fecha Hasta en la tabla). En consecuencia, ya no podremos definir la Clave de Negocio como un campo único, ya que pueden existir múltiples filas (múltiples versiones, tanto la actual como una o varias versiones históricas) con el mismo valor de la Clave de Negocio (Business Key). El campo id almacena un valor numérico único para cada fila de la tabla, actuando como una clave sustituta, de forma totalmente independiente a los datos de negocio. [guillesql.es]
• activo tinyint(1) NOT NULL DEFAULT '1'
  Permite realizar borrados lógicos ("UPDATE tabla SET activo = 0" en vez de "DELETE FROM tabla") de los datos de la tabla y de esta manera es fácil restaurar datos y mantener el histórico de los datos en la tabla.

Los siguientes campos son la fecha de inserción de la fila y del borrado lógico de la misma, para poder hacer un mejor seguimiento de las acciones. No me gusta incluir otros campos de auditoría como pueden ser el usuario de las acciones o fechas de modificación. Si estos datos son relevantes, prefiero guardarlos en otra tabla a modo de log.

• alta datetime NOT NULL
• baja datetime DEFAULT NULL

Y por último, los dos campos siguientes los incluyo cuando necesito que haya más de un registro de una determinada información, cada uno de los cuales tiene la información válida correspondiente a un cierto periodo de tiempo:

• inicio datetime NOT NULL
• fin datetime DEFAULT NULL

Por ejemplo, una tabla de impuestos en la que queremos poder consultar el porcentaje de IVA general que era válido en 2011 y el que está vigente ahora, según mi modelo tendría esta forma:

id	activo	alta	baja	inicio	fin	porcentaje_iva
1	1	15/06/2010 08:09:10		01/07/2010 00:00:00	31/08/2012 23:59:59	18
2	1	20/08/2012 11:10:09		01/09/2012 00:00:00		21