GUIDs como Chaves Primárias - Offline OLTP

Question

Estamos trabalhando na criação de um aplicativo que normalmente é OLTP (acho:sistema de aquisição).No entanto, este em particular, tem a necessidade que alguns usuários vão estar offline, por isso eles precisam ser capazes de transferir a base de dados para a sua máquina, trabalhar nele e, em seguida, a sincronização novamente, uma vez que está na LAN.

Gostaria de salientar que eu sei que isso foi feito antes, eu só não tenho experiência com este modelo específico.

Uma idéia que eu pensei foi o uso de GUIDs como tabela de chaves.Assim, por exemplo, uma Ordem de Compra não teria um número (auto-numérico), mas um GUID em vez disso, de modo a que cada cliente off-line pode gerar esses, e eu não tenho confrontos quando eu ligar de volta para o DB.

Esta é uma idéia ruim, por algum motivo?Terá acesso a estas tabelas através de chave GUID ser lento?

Você já teve experiência com este tipo de sistemas?Como você resolveu este problema?

Obrigado!
Daniel

Answer 1

O uso de Guids como chaves primárias, o que é aceitável e é considerado um padrão bastante prática para as mesmas razões que você está considerando.Eles podem ser usados em excesso, que pode tornar as coisas um pouco entediante para depurar e gerenciar, de modo a tentar mantê-los fora das tabelas de códigos e outros dados de referência, se possível.

A única coisa que você tem que se preocupar é o identificador legível por humanos.Guids não podem ser trocados por pessoas que você pode imaginar tentando confirmar o seu número de ordem sobre o telefone, se é um guid?Assim, em um offline cenário, você ainda pode ter para gerar algo - como um editor (estação de trabalho/usuário) identificação e algumas número de seqüência, de modo que o número de ordem pode ser 123-5678 -.

No entanto, isso pode não satisfazer requisitos de negócio de ter um número seqüencial.Na verdade, os requisitos regulamentares podem ser e influência - alguns regulamentos SOX (talvez) exigir que os números da fatura são seqüenciais.Em tais casos, ele pode ser necessário para gerar uma espécie de pró-número que é fixado até mais tarde, quando os sistemas de sincronizar.Você pode pousar com tabelas de ter OrderId (Guid), OrderNo (int), ProformaOrderNo (varchar) - alguns complexidade insinuar-se.

Pelo menos ter guids como chaves primárias significa que você não precisa fazer um monte de atualizações em cascata quando a sincronização, eventualmente, acontecer, você simplesmente atualizar o legível do número.

Answer 2

@SqlMenace

Há outros problemas com GUIDs, você vê o Guid não são sequenciais, para inserções serão espalhados por todo o lugar, isso faz com que as divisões de página e a fragmentação do índice

Não é verdade. Chave primária != índice de cluster.

Se o índice de cluster é outra coluna ("inserted_on" vem à mente), em seguida, as inserções serão seqüenciais e sem divisões de página ou fragmentação excessiva irá ocorrer.

Answer 3

Este é um perfeitamente bom uso de GUIDs.O empate só faz seria uma ligeira complexidade no trabalho com GUIDs sobre INTs e a ligeira diferença de tamanho (16 bytes vs 4 bytes).

Eu não acho que nenhum desses são um grande negócio.

Answer 4

Terá acesso a estas tabelas através de a chave GUID ser lento?

Há outros problemas com GUIDs, você vê o Guid não são sequenciais, para inserções serão espalhados por todo o lugar, isso faz com que as divisões de página e a fragmentação do índice

No SQL Server 2005 MS introduzido NEWSEQUENTIALID() para corrigir este problema, o único problema para você, pode ser que você só pode usar NEWSEQUENTIALID como um valor padrão em uma tabela

Answer 5

Você está certo que este é um problema antigo, e tem duas soluções canônicas:

• O uso de identificadores únicos, como a chave primária.Observe que, se você está preocupado com a legibilidade você pode lançar seu próprio identificador único, em vez de usar um GUID.Um identificador exclusivo vai usar a informação sobre a data e a máquina para gerar um único valor.

• Usar uma chave composta de 'Ator' + identificador.Cada usuário recebe um valor numérico ator ID, e as teclas de linhas recém-inseridas use o ator de IDENTIFICAÇÃO, bem como a próxima identificador.Assim, se dois atores inserir uma nova linha com a IDENTIFICAÇÃO de "100", a restrição de chave primária não será violada.

Pessoalmente, eu prefiro a primeira abordagem, como eu acho que chaves compostas são realmente tedioso como chaves estrangeiras.Eu acho que os humanos legibilidade reclamação é exagerada -- os usuários finais não deve saber nada sobre as suas chaves, de qualquer forma!

Answer 6

Certifique-se de utilizar guid.pente - cuida da indexação coisas.Se você está lidando com problemas de desempenho depois que, em seguida, você será, em curto espaço de tempo, um perito em escala.

Outro motivo para usar o Guid é permitir a refatoração de banco de dados.Digamos que você decidir aplicar polimorfismo ou a herança ou o que quer para os seus Clientes entidade.Agora você quer que os Clientes e Funcionários derivar da Pessoa e peça-lhes que contem uma tabela.Ter realmente identificadores exclusivos faz migração de dados simples.Não há sequências ou de identidade de número inteiro campos para lutar com.

Answer 7

Eu só vou ao ponto de você Quais são as melhorias de desempenho do Guid Sequencial sobre o padrão Guid?, que cobre o GUID falar.

Para a legibilidade, considere a atribuição máquina de Identificações e, em seguida, usando números sequenciais a partir dessas máquinas como uma possibilidade.Isso vai exigir gerir a atribuição de máquina de Identificações, embora.Poderia ser feito em uma ou duas colunas.

Eu pessoalmente gostava de a SGUID resposta, embora.

Answer 8

Guids certamente vai ser mais lento (e utilizar mais memória do que o padrão inteiro chaves, mas se ou não essa é uma questão que vai depender do tipo de carga de seu sistema, irá ver.Dependendo do seu back-end DB, pode haver problemas com a indexação de campos guid.

O uso de guids simplifica toda uma classe de problemas, mas você paga por ele a parte de desempenho e também debuggability - digitação guids para aqueles consultas de teste vai envelhecer muito rápido!

Answer 9

O back-end será SQL Server 2005
Frontend / a Lógica da Aplicação será .Net

Além de GUIDs, você pode pensar em outras formas de resolver o "mala", que acontece quando o computador offline sincroniza os novos dados para o banco de dados central?
Quero dizer, se as chaves são INTs, eu vou ter que renumerar tudo ao importar basicamente.GUIDs vai poupar-me.

Answer 10

O uso de GUIDs salvou um monte de trabalho, quando tivemos a mesclagem de dois bancos de dados em um.

Answer 11

Se seu banco de dados é pequeno o suficiente para transferir para um computador portátil e trabalhar com ele off-line, você provavelmente não precisa se preocupar muito sobre as diferenças de desempenho entre ints e Guids.Mas não subestime o quão útil ints são quando o desenvolvimento e a resolução de problemas de um sistema!Você provavelmente terá que vir acima com algumas bastante complexas de importação/sincronização de lógica, independentemente de se você está ou não usando Guids, para que eles não podem ajudar tanto quanto você pensa.

Answer 12

@Simon,

Você aumentar muito bons pontos.Eu já estava pensando sobre o "temporário" "human-readable" números de eu gerar enquanto estiver offline, só que eu gostaria de recriar o sync.Mas eu queria evitar de fazer com chaves estrangeiras, etc.

Answer 13

gostaria de começar a olhar para o SQL Server Compact Edition para isso!Ajuda com todos os seus problemas.

Dados Arquitetura de Armazenamento de dados com SQL Server 2005 Compact Edition

É projetado especificamente para

Campo de força aplicações (inglês free fatty acids ffas).Inglês free fatty acids ffas geralmente compartilham um ou mais dos seguintes atributos

Eles permitem que o utilizador efectue a sua funções de trabalho enquanto estiver desconectado do o back-end da rede—em-site localização do cliente, na estrada, em um aeroporto, ou a partir de casa.

Inglês free fatty acids ffas geralmente são projetados para ocasionais de conectividade, o que significa que quando os usuários estão executando o cliente aplicação, que não precisa ter uma conexão de rede de qualquer tipo.Inglês free fatty acids ffas muitas vezes, envolvem vários clientes que pode simultaneamente o acesso e utilização de dados a partir do back-end de banco de dados, tanto em um ligado e desligado modo.

Inglês free fatty acids ffas deve ser capaz de replicar dados a partir do back-end de banco de dados para o bases de dados de clientes para o suporte offline.Eles também precisam ser capazes de replicar a modificação, adição ou exclusão de dados registros do cliente para o servidor quando o aplicativo é capaz de conectar-se à rede

Answer 14

O primeiro pensamento que vem à mente:Não MS concebido o conjunto de dados e modelo de 'DataAdapter' para oferecer suporte a cenários como este?

Eu acredito que eu li que a MS mudou seu conjunto de registos ADO modelo para o conjunto de dados atual modelo funciona muito bem também offline.E há também esse Serviços de sincronização para o ADO.NET

Eu acredito que eu tenho visto de código que utiliza o conjunto de dados do modelo, que também usa chaves estrangeiras e eles ainda sincronizar perfeitamente quando utilizar o 'DataAdapter'.Havn't experimentar os Serviços de Sincronização, mas apesar de eu pensar que você pode ser capaz de se beneficiar também.

Espero que isso ajude.

Answer 15

@Portman Por padrão PK == Índice de Cluster, criando uma restrição de chave primária irá criar automaticamente um índice de cluster, você precisará especificar não agrupada se você não quer que ele cluster.