Selecionando uma chave primária adequada para um ambiente distribuído
Para tabelas que participam da sincronização incremental, o Sync Framework exige que cada linha seja identificada de forma exclusiva. Isso não é necessário para a sincronização de instantâneo do cliente e servidor. Normalmente, as linhas são identificadas por uma chave primária definida no servidor ou no banco de dados par. Em ambientes distribuídos, você deve ter cuidado ao selecionar o tipo de coluna usado como chave primária. As chaves primárias devem ser exclusivas em todos os nós e não devem ser reutilizadas. Se uma linha for excluída, a chave primária dessa linha não deverá ser usada para outra linha. Se uma chave primária for usada por mais de um nó, poderá ocorrer uma colisão de chave primária. Isso ocorre com qualquer tipo de ambiente distribuído, não sendo uma limitação do Sync Framework. Esse tópico descreve várias opções de chaves primárias e descreve sua adequabilidade para ambientes distribuídos.
Colunas de incremento automático (Identidade)
Os arquitetos de banco de dados geralmente selecionam uma coluna de incremento automático para servir como chave primária. Essa propriedade de incremento automático (a propriedade IDENTITY no SQL Server) gera um novo valor para cada registro inserido em uma tabela. Esse novo valor é gerado aumentando ou diminuindo o valor atual (a propagação) por uma soma fixa (o incremento) e atribuindo o resultado à linha que está sendo inserida. As colunas de incremento automático normalmente usam tipos de dados compactos, como números inteiros. Elas podem resultar em um índice clusterizado mais compacto, com junções mais eficientes e menos E/S quando a tabela subjacente for consultada.
No entanto, uma vez que as propriedades de propagação e incremento são fixas e podem ser selecionadas a partir de um número finito de valores possíveis, a probabilidade de uma colisão de chave primária ainda é alta. Esse tipo de chave é adequado para cenários de armazenamento de dados em cache somente para download. Nesses cenários, o servidor ou um par designado deve ser o único nó que gera novos valores de chaves primárias, garantindo, portanto, que esses valores sejam exclusivos em todos os nós na topologia. As colunas de incremento automático também serão adequadas para cenários bidirecionais e somente para upload se ocorrerem operações de inserção em apenas um nó. Nesses cenários, as operações de inserção geralmente ocorrem somente no servidor ou em um par designado, e as operações de atualização, e possivelmente as de exclusão, ocorrem em um ou mais clientes. Se as operações de inserção forem necessárias em mais de um nó, você deverá usar uma das outras abordagens descritas mais adiante neste tópico.
GUIDs
O uso de uma GUID (uma coluna uniqueidentifier no SQL Server) como chave primária garante a exclusividade em qualquer número de nós e elimina as possíveis colisões de chaves primárias com colunas de incremento automático. No entanto, o uso de uma GUID na chave primária tem as seguintes consequências:
O tipo de dados grandes (16 bytes) aumenta o tamanho do índice clusterizado, o que pode afetar contrariamente as operações comuns, como junções.
A geração não ordenada de GUIDs faz com que sejam inseridas linhas em locais aleatórios no índice clusterizado. Isso, por sua vez, pode gerar um índice clusterizado fragmentado, o que pode afetar contrariamente a E/S necessária para consultar a tabela subjacente.
No SQL Server 2005 e em versões posteriores, você pode usar a função NEWSEQUENTIALID() para gerar GUIDs seguindo uma ordem sequencial para ajudar a eliminar essa fragmentação.
Chaves que incluem um identificador de nó
Nesta abordagem, você pode usar uma chave que combina um valor exclusivo no nó do cliente ou do servidor com um valor exclusivo na topologia. Por exemplo, na sincronização do cliente e do servidor você pode usar uma coluna de incremento automático (exclusiva no nó) combinada com uma coluna que armazena um hash da ID que o Sync Framework atribui a cada cliente. (Esse é o ClientId exclusivo na topologia.) Em seguida, crie uma chave primária composta que tenha essas duas colunas. Opcionalmente, desenvolva um sistema para gerar os valores para cada linha inserida de modo que você possa incluir a ID da linha e a ID do cliente em uma coluna.
Chaves nativas
Com essa estratégia, você não usa qualquer tipo de chave fabricada, e sim uma chave comercial para identificar registros de maneira exclusiva. Por exemplo, uma tabela usada para armazenar as informações do cliente pode usar a coluna do número da previdência social como chave primária em vez de uma coluna de identidade. A desvantagem dessa abordagem é que a chave primária pode ser tornar muito grande se mais de uma coluna for necessária para identificar um registro de maneira exclusiva. Além disso, essa chave composta deve ser propagada para outras tabelas para dar suporte a uma ou mais relações de chave estrangeira. Essas relações, por sua vez, afetam contrariamente o desempenho da junção.
Inserção online
Se nenhuma das soluções anteriores for adequada e seu cenário exigir apenas algumas operações de inserção em um cliente, talvez seja viável que o aplicativo insira diretamente essas linhas no servidor. As novas linhas serão então baixadas e inseridas no cliente durante a próxima sincronização. Uma vez que os valores de chave primária são gerados no servidor, não ocorrerão colisões de chaves primárias.