Ver Mensaje Individual
  #8 (permalink)  
Antiguo 18/02/2016, 06:07
Avatar de gnzsoloyo
gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 16 años, 5 meses
Puntos: 2658
Respuesta: crear campo con prefijo increment

Te estás ahogando en un vaso de agua a mi entender, tal vez porque estás pensando en procesos, en lugar de pensar en datos.
Vamos a ver si entiendo.
Tienes N actividades que corresponden a los registros de N tablas, y necesitas crear una única entidad donde se almacenen los reportes de las acciones registradas en esas tablas, durante un X periodo de tiempo.
¿Algo así?

Bueno, si cada acción debe generar un ticket, y todos los tickets deben almacenarse en una única tabla, es perfectamente posible si:
1) Cada tabla origen de una acción es identificada por un código.
2) Cada acción en su propia tabla tiene un ID numérico o alfanumérico
3) Al ejecutarse el proceso indicado en su tabla el resultado se almacene en la tabla de tickets con CodigoProceso+ID tabla origen.
Ese par de datos compondría la PK de la tabla de tickets..

Esa es una solución que posee como problema que no podrías mantener la consistencia de datos entre los tickets y las otras tablas por FK, ya que una FK no puede apuntar a múltiples tablas. Te obligaría a mantener la consistencia programáticamente, con los riesgos que ellos implica.

Una segunda solución es aún mas sencilla, y consiste en plantear la solución entera de otro modo:
1) Una tabla de tickets con su PK basada en dos campos: un código de proceso, como antes, y un campo numérico que puede ser AI o no. La tabla ademas contendrá fecha de inserción, de inicio de proceso, de finalización de proceso, y estado de resultado.
2) La inserción de todos los procesos a realizar, sin importar cual sea, se reportan en esta tabla, insertándolos.
3) Las tablas de procesos heredan la PK de esta tabla (tablas hijas), y almacenan los restantes datos propios de ese proceso.
4) AL ejecutarse el proceso correspondiente, si termina bien o mal, se actualiza la tabla padre con fecha de terminación y estado. Los datos necesarios para ese update estan en la propia PK de la tabla ija.

La ventaja de este modelo es que puedes aumentar la cantidad de tipos diferentes de proceso sin necesidad de otro cambio que crear una tabla hija adicional por cada uno. El resto de la logica permanece constante.

¿Se entiende la idea?
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)