[lbuelvas]

Hola foristas, un cordial saludo.

Pues les voy a contar una experiencia reciente respecto a un sistema para cobro de catastro en Colombia (Impuesto Predial) donde el identificador de la tabla principal del sistema era el la cédula catastral de los inmuebles, todo estaba perfecto pero el gobierno cambio la estructura y contenido de esa cédula catastral. La decisión que tomé fue conservar como identificador la cédula catastral y hacer una conversión de datos, levantar llaves foráneas y actualizar todas las tablas donde se hacia referencia a la cédula catastral, y crear un campo para guardar la cédula catastral anterior.

Pero el problema se va a presentar en el futuro porque dentro de la cédula catastral hay 4 digitos que por el momento está en ceros (0000) pero que van a contener el codigo de Barrio / Vereda. Que sucede, esa concepción rompe el diseño de bases de datos pues eso 4 digitos no deberián forma parte de la llave primaria, la llave primaria depende de otras cosas para existir y puede variar en el tiempo y eso debe evitarse a toda costa.

Que me toca hacer ? Pues crear un identificador consecutivo oculto al usuario, crear una llave única (uk = unique key) para la cedula catastral porque eso si es seguro que no puede haber dos cedulas catastrales con igual valor.

Las consultas se pueden volver más complejas y más lentas y el trabajo de optimización se torna más importante.

Mi recomendación utiliza un consecutivo como identificador, utiliza el codigo del producto como llave alterna única UK (esto lo permite firbird) si y solamente si se garantiza que no habrá dos registros con igual código de producto.

Si el cliente por ejemplo quiere diferenciar por colores y tallas y los quiere manejar como productos diferentes los códigos también son distintos ?