É uma boa idéia usar rowguid como chave única em design de banco de dados?

Question

SQL Server fornece o tipo [rowguid]. Eu gosto de usar isso como chave primária única, para identificar uma linha para atualização. O benefício mostra-se despejar a tabela e recarregue-lo, não mexer com SerialNo (identidade) colunas.

No caso especial de bancos de dados distribuídos como cópias offline em notebooks ou algo assim, nada mais funciona.

O que você acha? Muita sobrecarga?

Answer 1

Como uma chave primária no sentido lógico (identificação exclusiva de suas linhas) - sim, absolutamente, faz total sentido

.

MAS: no SQL Server, a chave primária é, por padrão, também o chave de cluster na sua mesa, e usando um ROWGUID como a chave de cluster é realmente uma péssima idéia. Veja de Kimberly Tripp excelente GUIDs como um primário e / ou o artigo chave de cluster por razões detalhadas por que não GUIDs de uso para clustering.

Uma vez que o GUID é, por definição aleatória, você terá uma fragmentação do índice horrível e, portanto, realmente muito mau desempenho em insert, update, delete e selecione declarações.

Além disso, uma vez que a chave de cluster está sendo adicionado a cada campo de cada índice não agrupado na sua mesa, você está desperdiçando um monte de espaço - tanto no disco, bem como na RAM do servidor - quando se usa 16 bytes GUID vs de 4 bytes INT.

Assim: sim, como uma chave primária, uma ROWGUID tem seus méritos - mas se você usá-lo, definitivamente evitar o uso dessa coluna como seu chave de cluster na tabela! Use um INT IDENTITY () ou algo semelhante para isso.

Para uma chave de cluster, idealmente você deve olhar para quatro características:

• estável (nunca mudando)
• única
• tão pequeno quanto possível
• crescente

INT IDENTITY () idealmente ternos que precisam. E sim - a chave de cluster deve ser igual, pois é usado para localizar fisicamente uma linha na tabela - se você escolher uma coluna que não pode ser garantido para ser único, SQL Server vai realmente adicionar um uniqueifier quatro bytes para o seu chave de cluster - mais uma vez, não é algo que você quer ter ....

Confira O Clustered Index Debate Continua - outro artigo maravilhoso e perspicaz por Kim Tripp (a "Rainha da indexação SQL Server"), no qual ela explica todos esses requisitos muito bem e completamente

.

MArc

Answer 2

O problema com rowguid é que se você usá-lo para o seu índice agrupado você acaba constantemente re-cálculo suas páginas da tabela para inserções de discos. Um GUID seqüencial (NEWSEQUENTIALID ()) muitas vezes funciona melhor.

Answer 3

Nossa aplicação offline é usado em escritórios de filiais e temos um banco de dados central em nosso escritório principal. Para sincronizar o banco de dados em banco de dados central que temos coluna rowguid usado em todas as mesas. Pode ser há melhores soluções, mas é mais fácil para nós. Nós não enfrentou qualquer problema importante até a data no último 3 anos.

Answer 4

Ao contrário do que a resposta aceita, o tipo de dados uniqueidentifier no SQL Server é realmente um bom candidato para uma chave de cluster primário; contanto que você mantê-lo sequencial.

Isto é facilmente conseguido usando (newsequentialid ()) como o valor padrão para a coluna.

Se você realmente ler o artigo de Kimberly Tripp você vai achar que GUIDs gerados sequencialmente são realmente um bom candidato para chaves de cluster primário em termos de fragmentação ea única desvantagem é o tamanho.

Se você tem grandes linhas com alguns índices, os poucos bytes extra no GUID pode ser insignificante. Claro que os compostos problema se você tiver linhas curtas com vários índices, mas isso é algo que você tem que pesar dependendo da sua própria situação.

Usando uniqueidentifiers sequenciais faz muito sentido quando você está indo para replicação de mesclagem uso, especialmente quando se lida com a semeadura identidade e as desgraças que se seguem.

armazenamento calss Server não é barato, mas eu prefiro ter um banco de dados que usa um pouco mais de espaço do que aquele que screeches a um impasse quando sua identidade atribuído automaticamente varia sobreposição.