Consulta de buenas prácticas en Bases de Datos

[suchosyg]

Hola a todos, hace tiempo queria poner este tema a disposición de ustedes. Durante los trabajos que tuve, al observar las Bases de datos, siempre encontre tablas de registros históricos separada de la de registros actuales y mi primera pregunta para saber si esto es una buena práctica es:

-¿Los registros actuales deberían ir junto a los históricos en la misma tabla?
-¿No genera redundancia en una base de datos tener dos tablas casi iguales?

Y la segunda pregunta va más por el lado de los gestores de Bases de datos y el uso que le dan al elemento Auto_Increment:

-¿Es buena práctica que la Llave Primaria sea un Identificador Auto_Increment?

Todas estas preguntas me rondaban la cabeza durante algun tiempo y luego de leer las Formas Normales de bases de datos no encontre ideas que me resolvieran estas preguntas.

Espero sus opiniones

Saludos

[Libras]

Las tablas de historicos por lo general son para tener un respaldo de la informacion "actual" o en "linea", estos son utiles por si te llegan a pedir un reporte de informacion que ya no existe o muy vieja(no es recomendable guardar mucha info en una tabla) por ejemplo tienes tu tabla ventas y cada 3 meses eliminas informacion vieja de esta tabla y para no perderla la guardas en un historico, asi cuando haces un consulta a la tabla de ventas no recorres todas tus ventas solo las de 3 meses hacia adelante y las consultas de mas tiempo pues no son muy recurrentes.

Si es buena practica que el id sea autoincrement pero hay que ver si esa tabla va a tener muchos borrados de informacion me explico, es decir si sabes que va a ser una tabla donde la info no se elimine(por ejemplo usuarios) es bueno tener un autoincrement ya que puedes manejar que en lugar de eliminar un registro te lo marque como delete=0 digo.......

Saludos!

[gnzsoloyo]

En realidad las auto_increment son una mala práctica, considerados desde la optica del diseño de bases de datos. Son fáciles para los programadores, simples de implementar, eficientes a la hora de usarlas... pero problemáticas para migraciones, consolidación de datos, integración de sistemas, etc.

Según las reglas de normalización de base de datos, los ID numéricos y autonuméricos sólo se deben usar si llegados a la 3FN aún no se ha hallado una clave candidata. De lo contrario, la CC es siempre la mejor opción.
La idea parte desde el concepto que siempre existe, para una entidad dada, una clave capaz de identificar unívocamente una instancia de esa entidad entre todas las entidades del universo representado.
En otras palabras: Siempre existe una clave tal que permita identificar a una única persona en medio de los miles de millones de habitantes del planeta. Que esa clave sea de un sólo campo o requiera más de uno, no importa: lo importante es la unicidad de esa clave.

La gran ventaja de usar una clave irrepetible que no requiera un autoincremental es que su valor puede ser portado a diferentes sistemas, e integrado a diferentes modelos de bases sin necesidad de sacar o poner valores que no pertenezcan a esa instancia.
Un ejemplo de esto es, por ejemplo, un libro de una biblioteca. Si lo cambias de biblioteca (por la razón que sea), deberá ser vuelto a numerar, clasificar, identificar, si usas una secuencia incremental para ello. Pero si usas su ISBN, lo único que necesitas es ponerle un número ejemplar.
A nivel de integración de datos la problemática es parecida: Si tienes que integrar datos de clientes de diferentes sucursales, no sirven los autoincrementales, porque para poder pasar datos de una base a otra tienes que corregir la numeración de todos los autoincrementales usados en las diferentes tablas, y que son FK en otras... El proceso de integración se vuelve infernal. En cambio, si el ID es universalmente único, es casi todo una simple copia de datos.

¿Se entiende la problemática?

En definitiva, si vas a trabajar con bases distribuidas, masivas, datawarehouses, o integrables a futuro, los autoincrementales son una muy mala idea.

MySQL, por ejemplo, admite técnicas que permiten usar autoincrementales tales que puedas planear integrar a futuro, numerando con un paso de incremento diferente a +1. Pero en todos los casos sirven si y sólo si el número de bases usadas es fijo o se reduce, pero no si se aumenta.
Esto significa que si tienes cuatro sucursales, se puede hacer que cada una tenga una secuencia de incremento que hará que los datos no se solapen, e incluso puedes luego eliminar alguna sucursal. Lo que no puedes hacer es aumentar el número de ellas, porque la siguiente (5) generaría solapamiento de datos entre las bases... En otras palabras, su utilidad es relativa.

Más o menos por allí anda la cosa.

[suchosyg]

Gracias a Libras y a gnzsolyo por sus respuestas, me aclararon el panorama