PK como ROWGUIDCOL ou usar uma coluna separada do rowguid?

9

Há um longo debate aqui, então eu gostaria de ouvir outras opiniões.

Eu tenho muitas tabelas com PK em cluster uniqueidentifier. Se essa é uma boa ideia, está fora do escopo aqui (e não vai mudar tão cedo).

Agora, o banco de dados precisa ser publicado por mesclagem e os DEVs estão defendendo o uso de uma coluna de guia de linha separada em vez de marcar a PK existente como ROWGUIDCOL.

Basicamente, eles dizem que o aplicativo nunca deve trazer para o seu domínio algo que é usado apenas por replicação (são apenas "coisas de DBA" para eles).

Do ponto de vista do desempenho, não vejo razão para adicionar uma nova coluna para fazer algo que eu poderia fazer com uma existente. Além disso, como são apenas "coisas do DBA", por que não deixar o DBA escolher?

Eu meio que entendo o ponto dos DEVs, mas ainda discordo.

Pensamentos?

EDIT: Quero apenas acrescentar que sou minoria neste debate e os DEVs que questionam minha posição são pessoas que eu respeito e confio. Esta é a razão pela qual recorri a pedir opiniões.
Também posso estar faltando alguma coisa e ter entendido mal o que eles querem dizer.

sql-server database-design merge-replication

— spaghettidba
fonte

Existe alguma chance de que um valor de PK precise ser alterado no futuro?

— Robert L Davis

Não, na verdade não. É uma chave substituta, portanto o aplicativo realmente não faz muito com essa coluna. Isso nunca muda e nunca é exibido para os usuários.

— Spaghettidba

Por que eles querem um rowguidcol separado? E que esquema em geral eles escolheriam, se pudessem, para o PK, e por quê?

— JustinC 30/05

@spaghettidba Por falar em atravessar domínios, com que frequência você lhes diz quais padrões de design eles deveriam ou não deveriam usar no código do aplicativo? Talvez eles devessem manter seu "domínio"? ;-). Além disso, adicionar uma coluna de 16 bytes a todas as tabelas seria péssimo para o desempenho e não proporcionaria nenhum benefício.

— Solomon Rutzky,

7

Basicamente, eles dizem que o aplicativo nunca deve trazer para o seu domínio algo que é usado apenas por replicação (são apenas "coisas de DBA" para eles).

Eu concordo completamente. Mas ... a chave primária não é usada apenas para replicação (presumivelmente o aplicativo a usa de alguma maneira). O argumento não faz sentido neste contexto.

De qualquer forma, até onde sei, existem apenas duas maneiras para esse "material DBA" ultrapassar o limite do domínio:

Se o aplicativo estiver usando consultas que referenciam a ROWGUIDCOLcoluna assim:
```
DECLARE @a table (id uniqueidentifier ROWGUIDCOL);

SELECT ROWGUIDCOL FROM @a;
```
Suponho que nenhuma de suas colunas ainda tenha essa propriedade, portanto o aplicativo não faria isso. (A propósito, ROWGUIDCOLé um conceito completamente separado da replicação. Acontece que a replicação de mesclagem o usa.)
A coluna da chave primária não seria mais atualizável. Se o aplicativo estiver fazendo isso e as alterações não forem feitas para usar outro algoritmo, não há escolha a não ser adicionar uma nova coluna à tabela e, portanto, nenhuma discussão é necessária.

Além desses comportamentos, a ROWGUIDCOLpropriedade é completamente transparente. Você pode adicioná-lo e o aplicativo nunca saberia. Qualquer tipo de cenário de replicação de dados deve ser o mais transparente possível para os aplicativos.

— Jon Seigel
fonte

Obrigado por responder. Não, o aplicativo não está executando 1. nem 2. Por questões de integridade, algumas tabelas já estão decoradas com a propriedade ROWGUIDCOL no PK.

— Spaghettidba

Embora eu concorde que a replicação deva ser transparente para os aplicativos, também acredito que os bancos de dados que precisam ser publicados devem ser pensados para replicação desde o início. O gerenciamento de identidades na replicação de mesclagem é totalmente PITA, por exemplo: se você sabe desde o início que precisará mesclar a publicação, é uma coisa para ficar longe.

— Spaghettidba

@spaghettidba: Sim, concordo totalmente que, se houver replicação nos cartões, o banco de dados definitivamente terá que ser projetado para isso. Freqüentemente, simplesmente seguir as melhores práticas será o mais importante; são os bancos de dados herdados e feios e peludos que tendem a ter mais problemas de design. Da minha experiência, a replicação de mesclagem, em particular, é mais desafiadora do que qualquer outro mecanismo de replicação.

— Jon Seigel 31/05

@spaghettidba e Jon: Apenas para sua informação, o uso ROWGUIDCOLdesse contexto (ou seja, não em uma declaração CREATE TABLE/ ALTER TABLE) foi preterido desde pelo menos o SQL Server 2008 R2 (procure o FeatureID 182) a favor de $ROWGUID.

— Solomon Rutzky,

6

Concordo. Desde que não seja necessário alterar o valor de PK, seria melhor usar a coluna uniqueidentifier existente como o rowguidcol.

— Robert L Davis
fonte

5

"Basicamente, eles dizem que o aplicativo nunca deve trazer para o seu domínio algo que é usado apenas por replicação (são apenas" coisas de DBA "para eles)."

Mas não é usado apenas para replicação. É também (e já) o seu PK.

— Robert Zeurunkl
fonte