[SOLUCIONADO] Campo autoincrementado por bloques para PK compuesta

[NSD]

Hola gente, el titulo no es muy claro, perdon.

Lo que quiero hacer es lo siguiente, tengo una tabla tickets y otra tabla visitas.

Tickets:
id_ticket | descripcion
Visitas:
id_ticket | nro_visita | descripcion

Las visitas dependen del ticket, tickets.id_ticket es PK autoincremental.
Visitas.id_ticket es FK de tickets.id_ticket.

La PK de visitas se forma por id_ticket+nro_visita (es una entidad debil que depende de ticket para existir)

Hasta aca todo bien, el tema es el siguiente, quiero que nro_visita se autoincremente en cada insercion (no es un campo que el usuario pueda modificar, lo genera solo el sistema) pero con respecto al id_ticket, si le pongo autoincrement, el codigo se genera pero es correlativo a la cantidad total insertada y no a la cantidad de visitas del ticket.

Por ejemplo:

Tickets:

1 | ticket 1
2 | ticket 2
3 | ticket 3

Esto es lo que quiero lograr:

Insertar "Desc Visita 1" para el ticket 1:
1 | 1 | Desc Visita 1
Insertar "Desc Visita 2" para el ticket 1:
1 | 1 | Desc Visita 1
1 | 2 | Desc Visita 2
Insertar "Desc Visita 1" para el ticket 2:
1 | 1 | Desc Visita 1
1 | 2 | Desc Visita 2
2 | 1 | Desc Visita 1
Eliminar "Desc Visita 2" para el ticket 1:
1 | 1 | Desc Visita 1
2 | 1 | Desc Visita 1
Insertar "Desc Visita 3" para el ticket 1:
1 | 1 | Desc Visita 1
2 | 1 | Desc Visita 1
1 | 3 | Desc Visita 3

Es decir, que el nro se comporte como un autoincrement pero para cada ticket.

He pensado en crear una tabla aparte para llevar el control de los id y usar trigger para que se actualice sola, pero no me convence del todo, ¿Existira otra forma de implementarlo? Preferentemente solo con SQL, no quisiera involucrar al otro lenguaje en esta tarea.

[gnzsoloyo]

Es más simple implementar el alta por medio de un stored procedure donde realizas una consulta previa para contar cuántos registros hay con el mismo ticket, y de ese modo puedas calcular cuál es el valor que corresponda.
También puedes hacerlo por trigger, pero por SP es un poco más "limpio" si necesitas corregir errores de programación. Los TRIGGERs pueden dar algunos dolores de cabeza.

[NSD]

En el caso de usar SP igual tengo que tener la tabla auxiliar para contar los ids si se borraron verdad?

[gnzsoloyo]

Por una cuestion de consistencia de datos, no es recomendable borrar físicamente. Siempre es mejor desactivarlo, cosa que suele hacerse agregando un campo de fecha_baja, nulable, lo mismo que el fecha_alta. Es lo que se denomina "baja lógica"
El campo fecha_baja es null a menos que se lo "borre" virtualmente.
Además facilita el seguimiento y trazabilidad.

[NSD]

mmm Si, supongo que la baja logica es buena idea, pero en este caso en particular tengo todo el sistema con bajas fisicas, pero me diste la idea, en vez de una tabla auxiliar en tickets voy a tener un campo mas llamado visitas_ai el cual voy a usar para llevar el control autoincremental.

Gracias por la sugerencia

Saludos