SQL Server GUID (a partir do Active Directory) vs Int

Question

Nós migramos muitos dados do nosso sistema de encomendas de idade. Este sistema armazenadas as iniciais de usuários em nossa tabela "Pedidos" para cada ordem que eles criaram. Agora que temos uma visão que olha para Active Directory gostaria de atualizar essas iniciais com o objectguid diretório ativo (ou algo que as referências a guid). Isso nos permitiria mudar as iniciais de usuários no diretório ativo, sem ter que se preocupar sobre como atualizar os "Pedidos" registros da tabela.

Eu li que o desempenho índice é sem brilho quando se utiliza guids vs ints. Uma maneira de possivelmente resolver isso é ter uma tabela que mapeia guids para ints em seguida, armazenar o valor int em nossa mesa pedidos. Isso seria uma boa ideia? Quaisquer pensamentos?

Answer 1

Eu supor que um user entidade já existe no seu projeto de banco de dados no entanto, se isso não acontecer, então eu acredito que a solução vai exigir isso.

Assim, supondo que o user entidade existe, como você descreveu, você poderia colocar o UserID (int) no ORDENS tabela, relacionando assim, todos relevantes user detalhes para um Ordem , ao invés de iniciais apenas (Nota: iniciais deve, sem dúvida, não ser armazenados no Ordem mesa, mas sim o user ou USER_DETAILS mesa, embora não o foco desta discussão).

Você pode então adicionar a coluna GUID à tabela user. Eu não acho que uma tabela de pesquisa em separado é necessário.

faz sentido?

Answer 2

desempenho Índice de GUIDs é, em geral, não é diferente de outros índices em um campo de 16 bytes. Onde os do GUID são mortais para o desempenho é quando você usá-los como em uma tabela chave de cluster SQL Server.

A tabela SQL Server é a chave de cluster e é fisicamente ordenados por essa chave. Uma vez que os GUIDs são, por natureza totalmente aleatória, isso leva a enorme fragmentação índice muito rapidamente, e, portanto, requer a) alimentação constante e cuidados e reorganização, mas b) ainda sofre mesmo se você reorganizar todas as noites. Então, realmente, a melhor prática seria evitar GUIDs (mesmo os novos "seqüenciais" GUIDs) para a sua chave de cluster.

Para mais informações de fundo e alguns excelentes write-ups sobre o porquê GUIDs fazer chaves em cluster muito pobres, consulte o blog da "Rainha da indexação", Kimberly Tripp:

• GUIDs como chave primária
• O debate índice agrupado continua ....
• o debate índice agrupado .... novamente!

Sua visão é mais valioso - lê-la, internalizá-la, segui-lo! Você não vai se arrepender.

Marc