Como manejar campo Identity con actualizaciones Externas

14/08/2003 - 19:42 por Christian | Informe spam
Hola!

Tengo el siguiente escenario. Un tabla con otras relacionadas que son un
Padrón de Beneficiarios. Se pueden dar Altas en casa central y en las
Filiales que se encuentran en el interior y no disponen de conexión online.
Casa Central debe tener los registros de los Beneficiarios de las sucursales
que se obtienen mediante procesos de actualizaciones (no mediante
replicación). Mi problema es con los campos Identity (que son PK), ya que
deben quedar igual que como fueron grabados en las sucursales. Por lo que
estuve leyendo lo mejor para eso es utilizar rangos de numeros en los campos
de Identity. Les pido si alguien tiene mas información acerca de esto, si
voy bien encaminado o si hay alguna solución mas fácil a esto.

Gracias a Todos

Preguntas similare

Leer las respuestas

#1 Javier Loria\(MVP\)
15/08/2003 - 04:07 | Informe spam
Hola Christian:
Hay varias alternativas, las 4 mas populares:
a) Por bloques: En esta caso simulas el comportamiento de un vendedor o un
cobrador que pide un "talorario" de recibos o facturas. En este caso cada
servidor pide un bloque de por ejemplo 100 numeros a la Oficina Central.
Esta informacion se registra en la BD Central, en una tabla dedicada a esta
funcion. Los servidores cuando van "gastando" numeros y cuando se acercan al
final piden otro bloque que la BD Central les otorga. Cuando llega el
momento se modifica el "Seed" del Identity para empezar el nuevo bloque.
b) Por multiplos: El servidor uno usa un Identity con incrementos de 10 e
iniciando en 1. O sea otorga: 1,11,21,31,etc. El servidor 2 igual pero
iniciando en 2: 2,22,32,42, etc.
c) Temporal: Las sucursales solo asginan un numero temporal (Identity
cualquiera) y en el momento que se ejecuta el proceso de actualizacion es la
Oficina Central la que asigna el numero definitivo. Hay que asegurarse que
Oficina Central nunca choque con el de la Sucursal.
d) Agregas una columna Sucursal a todas las tablas en cuestion, con un
DEFAULT y un CHECK que exija que sea el numero que asignaste a dicha
sucursal (o sea es una CONSTANTE) y, defines la llave Primaria sobre ambas
columnas. Usas el Identity como si nada.
La que a mi mas gusta no esta dentro de estas 4, y es remover el
Identity y usar alguna Llave Natural.

Saludos,



Javier Loria
Costa Rica (MVP)
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
Christian escribio:
Hola!

Tengo el siguiente escenario. Un tabla con otras relacionadas que
son un Padrón de Beneficiarios. Se pueden dar Altas en casa central y
en las Filiales que se encuentran en el interior y no disponen de
conexión online. Casa Central debe tener los registros de los
Beneficiarios de las sucursales que se obtienen mediante procesos de
actualizaciones (no mediante replicación). Mi problema es con los
campos Identity (que son PK), ya que deben quedar igual que como
fueron grabados en las sucursales. Por lo que estuve leyendo lo mejor
para eso es utilizar rangos de numeros en los campos de Identity. Les
pido si alguien tiene mas información acerca de esto, si voy bien
encaminado o si hay alguna solución mas fácil a esto.

Gracias a Todos
Respuesta Responder a este mensaje
#2 Christian
15/08/2003 - 14:39 | Informe spam
Muchas gracias por tu valiosa info

"Javier Loria(MVP)" escribió en el mensaje
news:
Hola Christian:
Hay varias alternativas, las 4 mas populares:
a) Por bloques: En esta caso simulas el comportamiento de un vendedor o un
cobrador que pide un "talorario" de recibos o facturas. En este caso cada
servidor pide un bloque de por ejemplo 100 numeros a la Oficina Central.
Esta informacion se registra en la BD Central, en una tabla dedicada a


esta
funcion. Los servidores cuando van "gastando" numeros y cuando se acercan


al
final piden otro bloque que la BD Central les otorga. Cuando llega el
momento se modifica el "Seed" del Identity para empezar el nuevo bloque.
b) Por multiplos: El servidor uno usa un Identity con incrementos de 10 e
iniciando en 1. O sea otorga: 1,11,21,31,etc. El servidor 2 igual pero
iniciando en 2: 2,22,32,42, etc.
c) Temporal: Las sucursales solo asginan un numero temporal (Identity
cualquiera) y en el momento que se ejecuta el proceso de actualizacion es


la
Oficina Central la que asigna el numero definitivo. Hay que asegurarse que
Oficina Central nunca choque con el de la Sucursal.
d) Agregas una columna Sucursal a todas las tablas en cuestion, con un
DEFAULT y un CHECK que exija que sea el numero que asignaste a dicha
sucursal (o sea es una CONSTANTE) y, defines la llave Primaria sobre ambas
columnas. Usas el Identity como si nada.
La que a mi mas gusta no esta dentro de estas 4, y es remover el
Identity y usar alguna Llave Natural.

Saludos,



Javier Loria
Costa Rica (MVP)
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
Christian escribio:
> Hola!
>
> Tengo el siguiente escenario. Un tabla con otras relacionadas que
> son un Padrón de Beneficiarios. Se pueden dar Altas en casa central y
> en las Filiales que se encuentran en el interior y no disponen de
> conexión online. Casa Central debe tener los registros de los
> Beneficiarios de las sucursales que se obtienen mediante procesos de
> actualizaciones (no mediante replicación). Mi problema es con los
> campos Identity (que son PK), ya que deben quedar igual que como
> fueron grabados en las sucursales. Por lo que estuve leyendo lo mejor
> para eso es utilizar rangos de numeros en los campos de Identity. Les
> pido si alguien tiene mas información acerca de esto, si voy bien
> encaminado o si hay alguna solución mas fácil a esto.
>
> Gracias a Todos


email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida