Início / dba / Perguntas / 43457
Accepted
spaghettidba
Asked: 2013-05-31 08:48:06 +0800 CST

PK como ROWGUIDCOL ou usar uma coluna separada de rowguid?

  • 772

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

Eu tenho muitas tabelas com PK clusterizado de identificador único. Se esta é uma boa ideia está fora do escopo aqui (e não vai mudar tão cedo).

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

Basicamente, eles dizem que o aplicativo nunca deve trazer para o seu domínio algo que é usado apenas para replicaçã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, já que são apenas "coisas de DBA", por que não deixar o DBA escolher?

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

Pensamentos?

EDIT: Só quero acrescentar que estou em minoria neste debate e os DEVs que questionam minha posição são pessoas que respeito e confio. Esta é a razão pela qual recorri a pedir opiniões.
Eu também posso estar perdendo alguma coisa e posso ter entendido mal o ponto deles.

sql-server database-design

3 respostas

  1. Best Answer

    Basicamente, eles dizem que o aplicativo nunca deve trazer para o seu domínio algo que é usado apenas para replicaçã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 forma). O argumento não faz sentido neste contexto.

    De qualquer forma, até onde eu sei, existem apenas 2 maneiras de esse "material de DBA" cruzar o limite do domínio:

    1. Se o aplicativo estiver usando consultas que fazem referência à ROWGUIDCOLcoluna como esta:

      DECLARE @a table (id uniqueidentifier ROWGUIDCOL);

SELECT ROWGUIDCOL FROM @a;

      Presumo que nenhuma de suas colunas tenha essa propriedade ainda, então 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.)

    2. A coluna de chave primária não seria mais atualizável. Se o aplicativo está fazendo isso e não serão feitas alterações 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 saberá. Qualquer tipo de cenário de replicação de dados deve ser o mais transparente possível para os aplicativos.

    • 7

  2. Concordo. Contanto que não haja necessidade de alterar o valor PK, seria melhor usar a coluna uniqueidentifier existente como o rowguidcol.

    • 6

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

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

    • 5

relate perguntas