Tablas con PKs Negativas
 

Tenemos un ERP al que estamos haciendo algunas ampliaciones y vamos a conectar a través de un sistema REST con una aplicación de terceros para poder añadir movimientos desde el exterior.

En nuestro sistema todas las tablas disponen de un ID que se autoalimenta a partir de generadores propios para cada una de las tablas.
Tenemos un Generador para cabeceras de albaranes, otro para líneas de albaranes, y así con todas las tablas.

Los registros que nos llegan a través de las peticiones REST tienen su propio ID y debemos asegurarnos de que no vamos a tener colisiones con IDs duplicados.
Estos registros pueden ser de alta, de modificación o de borrado, por lo que es necesario conservar de alguna forma el ID original.

Para solucionar el problema se me ocurren varias opciones.
1.- Tener un rango diferente de IDs para los movimientos externos.
Por ejemplo sumar 10.000.000 al ID original (no garantiza al 100% las colisiones)
2.- Conservar los IDs originales pero con signo negativo
3.- Añadir un campo a la tabla con el ID Externo.
4.- Una tabla intermedia que me relacione el ID externo con mi ID.

De todas estas opciones me decanto absolutamente por la de IDs negativos ya que, claramente, es la que representa menos trabajo y creo que es la más eficiente.

La pregunta:
Puedo tener algún problema en Firebird por el hecho de tener IDs, PKs, FKs con valores negativos.
He estado haciendo algunas pruebas y todo parece funcionar correctamente, pero desearía saber si alguien ha tenido alguna experiencia en este sentido.

Gracias por vuestros comentarios

Lo mas normal en esos casos, es que el modelo de datos del servidor, incluya en un campo la referencia al ID del registro del cliente, junto con el ID del cliente, y crear una clave única entre dos campos para evitar que un registro se inserte mas de una vez. Algo como tu punto 3.
En relación a tu pregunta, desconozco FireBird, pero la exigencia normal de los motores RDBMS suele ser que los campos que conforman la relación entre ambas tablas, conserven el mismo tipo de dato, sin importar el contenido.

Saludos.

Creo que lo más coherente es:
3.- Añadir un campo a la tabla con el ID Externo.

Yo creo que también me decantaría por la 3.
1) Mezclas "cosas diferentes" en un sólo campo; Se me ocurren problemas como que puedan coincidir los rangos o que tengas que hacer JOIN contra tablas diferentes por el mismo campo,...
2) (entiendo que los conservas en el mismo campo cambiando los actuales). Lo mismo de antes en el mismo campo guardas cosas diferentes. No se qué pasará si ya estás haciendo referencia a esos ID's en otros lugares. Código condicional dependiendo de si el valor de un campo es positivo o negativo. raro...
3) Creo que es la correcta. Normalizada y la más clara.
4) Sería la escogida si la relación entre ID/IDExterno fuera 1..N; Si la relación es 1..1, 1..0 se puede usar esta o la anterior.

Hola compañeros....

Muchas gracias por vuestras aportacions.

Veo que además estais deacuerdo en la solución a adoptar.

Lo comentamos con el equipo y tomaremos una decisión

Saludos a todos

También voto por la opción 3, aunque si por algún motivo no puedes agregar el campo, una tabla de relación es la solución.
En este último caso, no tienes que modificar la estructura original.
Además, si luego tienes mas de un origen de importaciones, puedes tener una tabla como esta:

Código SQL [-]
Create Table RelacionOrigenesExteriores(
Tipo varchar(3)
Origen varchar(10)
IdOrigen integer
IdPropio integer
FechaUltimaSincronizacion date
)