Problema con claves en replicacion

Hola:
Te copio una vieja respuesta:
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
wrote in message
news:
Gracias Jorge , te comento :

La idea de añadir un campo sucursal fue lo primero que pense,pero sin
darle muchas vueltas la descarte por tener que cambiar la aplicacion
(sobre todo al tener que eliminar la opcion de autoincremento de los
identitys)

La solución de los seeds la habia tenido en cuenta, pero la descarte
por lo que me comentas de que suele ser propensa a errores ( y mas que
nada , a lo problematico de la forma de solucionarlos) . Tampoco me
parecia una solución del todo idonea ni comoda , aunque no la descarto
completamente.

Lo valorare mas detenidamente si no existe otra solución.

El diseño no tiene en cuenta la replicación porque en un principio
esta aplicacion no estaba pensada ni remotamente para utilizarse en
varias sucursales

Gracias




Jorge Gonzalez ha escrito:

Estimado José Foros

Replicación es un tema complejo. No solamente conlleva la configuración
del
Servidor SQL para que replique tablas, hay todo un diseño que hacer sobre
el
rendimiento de los servidores, carga de trabajo (workload), peso de las
transacciones, etc, pero sobre todo, un tema de suma importancia es el
tema
de que el diseño de los datos debe tomar en cuenta que los datos serán
replicados. Es decir, que cuando construis el diseño de tablas, tenés que
pensar que esas tablas serán replicadas para luego evitar problemas como
el
tuyo. Yo he implementado con éxito 2 soluciones a tu problema:

1. Incluís un campo IdSucursal a cada tabla que puede contener datos
propios. Este campo debe ser parte de la llave primaria. Posiblemente
pueda
tener un valor por defecto en cada instalación de forma que tu aplicación
no
tenga que hacerse cargo de insertarlo cada vez. Así podés tener un campo
Identity como parte de la clave que no será duplicado en la llave primaria
ya que esta incluye el campo IdSucursal. Esto aplica a todas las tablas de
la base de datos que serán replicadas. Esta solución implica cambios
importantes en la aplicación. Pero es al final, más óptima y te evitará
problemas en el futuro.

2. A cada instalación le designás un rango de valores posibles para los
Identity. Por ejemplo, la sucursal 1 usará Identity del 1 al 10 millones,
la
sucursal 2 usará del 10,000,001 al 20,000,000 y así sucesivamente. Esta es
una solución funcional ya que al centralizar la información los Identity
no
se traslaparán. Toma en cuenta que para estoy hay que marcar los Identity
en
la base de datos central como NOT FOR REPLICATION. Además el nivel de
control sobre los SEED de los Identity es bien difícil ya que cualquier
error te puede causar estragos. Esta solución o implica ningún cambio en
tu
aplicación, pero es propensa a problemas y además tenés que hacer cambios
en
las bases de datos, en los SEED de los Identity.

Creo que vos vas a pagar el precio de no haber hecho el diseño tomando en
cuenta la replicación. Que es un precio alto. De acuerdo a mi experiencia
esas son las 2 posible soluciones y las 2 implican cambios importantes en
mayor o menor grado.

Si alguien conoce alguna solución menos compleja, será interesante
escucharla.

saludos
Jorge González
escribió en el mensaje
news:
Hola,os comento mi problema

Tengo un servidor "Central" que reparte trabajos a las distintas
"Sucursales"

A la hora de repartir los datos no hay problema , ya que localmente en
cada sucursal se intentara que no se trabaje nada mas que con los datos
de la central , asi todo he separado los datos de uno y de otro para
que no se solapen ( en local los ids son pares, y en la central
impares)

El problema me viene porque si yo envio un "trabajo" a la sucursal ,
esta , a fin de relizar ese trabajo insertara filas nuevas en las
tablas relacionadas al trabajo . Una vez se suba el trabajo a la
central , esas nuevas filas entraran en conflicto con las de otras
sucursales.A ver si con un ejemplo se ve mejor


Central -> envia el trabajo 1 -> Sucursal A
Central -> envia el trabajo 3 -> Sucursal B

Sucursal A crea un registro en una tabla relacionada al trabajo
,localmente , al ser el primer registro le dara el numero 1

Sucursal B crea un registro en una tabla relacionada al trabajo
,localmente , al ser el primer registro le dara el numero 1

Al subir los datos a la central , en esa tabla relacionada ,llegaran
dos registros con id numero 1

¿Existe alguna solucion viable para solventar esto? . Tanto en la
central como en las sucursales se trabaja con una aplicacion ya
realizada en la que no estaba previsto realizar estas tareas de
replicacion , cno lo que cuantos menos cambios realize en la base de
datos , menos tendre que tocar la aplicacion (lo digo mas que nada por
la posible solucion de eliminar los campos identity)

Gracias