Qual pode ser a desvantagem de sempre ter uma única coluna inteira como chave primária?

Em um aplicativo Web em que estou trabalhando, todas as operações do banco de dados são abstraídas usando alguns repositórios genéricos definidos no ORM do Entity Framework.

No entanto, para ter um design simples para os repositórios genéricos, todas as tabelas envolvidas devem definir um número inteiro exclusivo ( Int32em C #, intem SQL). Até agora, este sempre foi o PK da tabela e também o IDENTITY.

Chaves estrangeiras são muito usadas e fazem referência a essas colunas inteiras. Eles são necessários para consistência e para gerar propriedades de navegação pelo ORM.

A camada de aplicativo geralmente executa as seguintes operações:

• carregamento inicial de dados da tabela (*) -SELECT * FROM table
• Atualização -UPDATE table SET Col1 = Val1 WHERE Id = IdVal
• Excluir -DELETE FROM table WHERE Id = IdVal
• Inserir -INSERT INTO table (cols) VALUES (...)

Operações menos frequentes:

• Inserção em massa - BULK INSERT ... into tableseguida (*) por toda a carga de dados (para recuperar identificadores gerados)
• Exclusão em massa - esta é uma operação de exclusão normal, mas "volumosa" da perspectiva do ORM:DELETE FROM table where OtherThanIdCol = SomeValue
• Atualização em massa - esta é uma operação de atualização normal, mas "volumosa" da perspectiva do ORM:UPDATE table SET SomeCol = SomeVal WHERE OtherThanIdCol = OtherValue

* todas as tabelas pequenas são armazenadas em cache no nível do aplicativo e quase todas SELECTsnão atingem o banco de dados. Um padrão típico é carga inicial e muita INSERTs, UPDATEs e DELETEs.

Com base no uso atual do aplicativo, há uma chance muito pequena de atingir 100 milhões de registros em qualquer uma das tabelas.

Pergunta: Na perspectiva do DBA, existem problemas significativos com os quais posso ter essa limitação de design da tabela?

[EDITAR]

Depois de ler as respostas (obrigado pelo ótimo feedback) e os artigos referenciados, sinto que preciso adicionar mais detalhes:

1. Especificações atuais do aplicativo - não mencionei o aplicativo da Web atual, porque quero entender se o modelo também pode ser reutilizado para outros aplicativos. No entanto, meu caso particular é um aplicativo que extrai muitos metadados de um DWH. Os dados de origem são bastante confusos (desnormalizados de uma maneira estranha, com algumas inconsistências, sem identificador natural em muitos casos etc.) e meu aplicativo está gerando entidades separadas e claras. Além disso, muitos dos identificadores gerados ( IDENTITY) são exibidos, para que o usuário possa usá-los como chaves comerciais. Além de uma grande refatoração de código, isso exclui o uso de GUIDs .

2. "eles não devem ser a única maneira de identificar uma linha de maneira única" (Aaron Bertrand ♦) - esse é um conselho muito bom. Todas as minhas tabelas também definem uma restrição exclusiva para garantir que duplicatas de negócios não sejam permitidas.

3. Design orientado a aplicativos front-end vs. Design orientado a banco de dados - a escolha do design é causada por esses fatores

   1. Limitações do Entity Framework - PKs de várias colunas são permitidas, mas seus valores não podem ser atualizados

   2. Limitações personalizadas - ter uma única chave inteira simplifica muito as estruturas de dados e o código não-SQL. Por exemplo: todas as listas de valores têm uma chave inteira e valores exibidos. Mais importante, garante que qualquer tabela marcada para armazenamento em cache poderá colocar em um Unique int key -> valuemapa.

4. Consultas de seleção complexas - isso quase nunca acontece porque todos os dados de tabelas pequenas (<20-30K registros) são armazenados em cache no nível do aplicativo. Isso torna a vida um pouco mais difícil ao escrever o código do aplicativo (mais difícil de escrever o LINQ), mas o banco de dados é muito melhor:

   1. Exibições de lista - não gerará SELECTconsultas no carregamento (tudo está armazenado em cache) ou consultas com esta aparência:

      SELECT allcolumns FROM BigTable WHERE filter1 IN (val1, val2) AND filter2 IN (val11, val12)

      Todos os outros valores necessários são buscados por meio de pesquisas em cache (O (1)), portanto, nenhuma consulta complexa será gerada.

   2. Editar visualizações - gerará SELECTinstruções como esta:

      SELECT allcolumns FROM BigTable WHERE PKId = value1

(todos os filtros e valores são ints)

Além de espaço em disco adicional (e, por sua vez, uso de memória e E / S), não há nenhum mal em adicionar uma coluna IDENTITY mesmo a tabelas que não precisam de um (exemplo de uma tabela que não precisa de uma coluna IDENTITY é uma tabela de junção simples, como mapear um usuário para suas permissões).

Eu me oponho a adicioná-los às cegas em todas as tabelas de um post de 2010:

• Maus hábitos para chutar: colocar uma coluna de IDENTIDADE em todas as mesas

Porém, as chaves substitutas têm casos de uso válidos - apenas tome cuidado para não supor que eles garantam exclusividade (e às vezes é por isso que são adicionados - eles não devem ser a única maneira de identificar exclusivamente uma linha). Se você precisar usar uma estrutura ORM, e sua estrutura ORM exigir chaves inteiras de coluna única, mesmo nos casos em que sua chave real não for um número inteiro, ou uma coluna única, ou nenhuma, verifique se você definiu restrições / índices exclusivos para suas chaves reais também.

Pela minha experiência, o principal e principal motivo para usar um ID separado para cada tabela é o seguinte:

Em quase todos os casos, meu cliente fez um juramento de sangue na fase de concepção de que algum campo externo "natural" XYZBLARGH_IDpermanecerá único para sempre, nunca mudará para uma determinada entidade e nunca será reutilizado, eventualmente surgiram casos em que o As propriedades da Chave Primária foram quebradas. Simplesmente não funciona dessa maneira.

Então, do ponto de vista do DBA, as coisas que tornam um banco de dados lento ou inchado certamente não são 4 bytes (ou o que for) por linha, mas coisas como índices errados ou ausentes, reorganizações esquecidas de tabela / índice, parâmetros de ajuste de RAM / espaço de tabela incorretos , deixando de usar variáveis ​​de ligação e assim por diante. Aqueles podem diminuir a velocidade do banco de dados por fatores de 10, 100, 10000 ... não uma coluna de ID adicional.

Portanto, mesmo que houvesse uma desvantagem técnica e mensurável de ter 32 bits adicionais por linha, não se trata de otimizar o ID, mas se o ID será essencial em algum momento, o que será mais provável que não. E não vou contar todos os benefícios "flexíveis" de uma postura de desenvolvimento de software (como o exemplo do ORM, ou o fato de facilitar para os desenvolvedores de software quando todos os IDs projetados tiverem o mesmo tipo de dados e assim por diante) .

NB: observe que você não precisa de um ID separado para n:mtabelas de associação, pois para essas tabelas os IDs das entidades associadas devem formar uma chave primária. Um contraexemplo seria uma n:massociação estranha que permite várias associações entre as mesmas duas entidades por qualquer motivo bizarro - elas precisariam de sua própria coluna de ID para criar uma PK. Porém, existem bibliotecas ORM que não podem manipular PKs de várias colunas, portanto, esse seria um motivo para ser indulgente com os desenvolvedores, se eles precisassem trabalhar com essa biblioteca.

Se você invariavelmente adicionar uma coluna extra sem sentido a todas as tabelas e fizer referência apenas a essas colunas como chaves estrangeiras, quase inevitavelmente tornará o banco de dados mais complexo e difícil de usar. Efetivamente, você removerá os dados de interesse dos usuários dos atributos da chave estrangeira e forçará o usuário / aplicativo a fazer uma associação extra para recuperar as mesmas informações. As consultas se tornam mais complexas, o trabalho do otimizador se torna mais difícil e o desempenho pode sofrer.

Suas tabelas serão mais escassamente preenchidas com dados "reais" do que seriam de outra forma. O banco de dados será, portanto, mais difícil de compreender e verificar. Você também pode achar difícil ou impossível impor certas restrições úteis (onde as restrições envolvem vários atributos que não estão mais na mesma tabela).

Eu sugiro que você escolha suas chaves com mais cuidado e faça-as inteiras somente se / quando você tiver boas razões. Baseie seus projetos de banco de dados em boas análises, integridade de dados, praticidade e resultados verificáveis, em vez de confiar em regras dogmáticas.

Na minha experiência com vários bancos de dados, uma chave primária Inteira é sempre melhor do que os aplicativos que não possuem chaves definidas. Ou que têm chaves que juntam meia dúzia de colunas varchar de maneiras estranhas que não são lógicas ... (suspiro)

Já vi aplicativos que alternavam de PKs inteiros para GUIDs. A razão para isso foi porque havia a necessidade de mesclar dados de vários bancos de dados de origem em certos casos. Os desenvolvedores mudaram todas as chaves para GUIDs para que as mesclagens pudessem ocorrer sem medo de colisões de dados, mesmo em tabelas que não faziam parte da mesclagem (apenas no caso de essas tabelas se tornarem parte de uma mesclagem futura).

Eu diria que um PK inteiro não vai morder você, a menos que você planeje mesclar dados de fontes separadas ou você possa ter dados que vão além dos limites de tamanho inteiro - é tudo divertido e jogos até você ficar sem espaço para inserções .

Eu direi, no entanto, que pode fazer sentido definir seu índice clusterizado em uma coluna diferente da sua PK, se a tabela for consultada com mais frequência dessa maneira. Mas esse é um caso externo, especialmente se a maior parte das atualizações e seleções forem baseadas nos valores de PK.

Pondo de lado:

• As guerras religiosas (google substituto vs chave natural)
• A questão separada de quais índices em cluster definir em suas tabelas
• A viabilidade de armazenar em cache todos os seus dados

Desde que você esteja usando a exclusão / atualização em massa, quando apropriado, e possua índices para dar suporte a essas operações, acho que você não terá problemas devido ao padrão PK usado.
É possível que, se você tiver o EF mais tarde, gerar consultas com junções, etc., que elas não sejam tão eficientes quanto seriam em um repositório baseado em chave natural, mas eu não sei o suficiente sobre essa área para dizer com certeza de qualquer maneira.

Você tem alguns fatores para ajudá-lo,

1. Definição e especificações.

   Se algo é definido como único pela tarefa ou pelas leis da física, você está perdendo seu tempo com uma chave substituta.

2. Singularidade.

   Para sanidade pessoal, junções e funcionalidade de banco de dados de nível superior, você precisará de: (a) coluna exclusiva, (b) série exclusiva de colunas

   Todos os esquemas suficientemente normalizados (1NF) fornecem um dos seguintes. Caso contrário, você deve sempre criar um. Se você tem uma lista de pessoas como voluntária no domingo, e inclui sobrenome e nome, convém saber quando tiver dois Joe Bobs.

3. Implementação e otimização.

   Um int tende a ser um pequeno formulário de dados que é rápido para comparação e igualdade. Compare isso com uma cadeia Unicode cujo agrupamento pode depender da localidade (local e idioma). Armazenar um 4242 em uma sequência ASCII / UTF8 é de 4 bytes. Armazená-lo como um número inteiro cabe em 2 bytes.

Então, quando se trata de desvantagens, você tem alguns fatores.

1. Confusão e ambiguidade.

   1. A entrada do blog @Aaron Bertrand resume bem isso. Não é auto-documentado ter um OrderID pela especificação e tarefa e, em seguida, impor um " OrderID " por meio da implementação do banco de dados. Às vezes, você precisa esclarecer isso ou criar uma convenção, mas é provável que isso adicione confusão.

2. Espaço.

   Os números inteiros ainda adicionam espaço à linha. E, se você não os estiver usando, não há propósito.

3. Clustering.

   Você só pode solicitar seus dados de uma maneira. Se você impõe uma chave substituta desnecessária, você agrupa dessa maneira ou da maneira da chave natural?