Strings como chaves primárias no database SQL

Eu não estou muito familiarizado com bancos de dados e as teorias por trás de como eles funcionam. É mais lento do ponto de vista do desempenho (inserir / atualizar / consultar) para usar Strings for Primary Keys do que inteiros?

Tecnicamente, sim, mas se uma string faz sentido como a chave primária, provavelmente você deve usá-la. Isso tudo depende do tamanho da tabela que você está fazendo e do comprimento da string que será a chave primária (strings mais longas == mais difíceis de comparar). Eu não usaria necessariamente uma string para uma tabela que tivesse milhões de linhas, mas a lentidão do desempenho que você obteria usando uma string em tabelas menores seria minúscula para as dores de cabeça que você pode ter ao ter um número inteiro que não significa nada em relação aos dados.

Outro problema com o uso do Strings como uma chave primária é que, como o índice é colocado constantemente em ordem sequencial, quando uma nova chave é criada que estaria no meio da ordem, o índice precisa ser resequenciado … se você usar um auto número inteiro, a nova chave é apenas adicionada ao final do índice.

Insere em uma tabela com um índice clusterizado onde a inserção ocorre no meio da seqüência não faz com que o índice seja reescrito. Não faz com que as páginas que contêm os dados sejam reescritas. Se houver espaço na página em que a linha irá, ela será colocada nessa página. A única página será reformatada para colocar a linha no lugar certo na página. Quando a página estiver cheia, uma divisão de página acontecerá, com metade das linhas da página indo para uma página e outra metade indo para a outra. Em seguida, as páginas são vinculadas novamente à lista de páginas vinculadas que compõem os dados de tabelas que possuem o índice clusterizado. No máximo, você vai acabar escrevendo 2 páginas de database.

As strings são mais lentas na junit e na vida real raramente são realmente únicas (mesmo quando deveriam ser). A única vantagem é que eles podem reduzir o número de junções se você estiver ingressando na tabela principal apenas para obter o nome. No entanto, as strings também estão sujeitas a alterações, criando assim o problema de ter que corrigir todos os registros relacionados quando o nome da empresa muda ou a pessoa se casa. Isso pode ser um grande impacto no desempenho e se todas as tabelas que devem estar relacionadas de alguma forma não estiverem relacionadas (isso acontece com mais frequência do que você pensa), então você pode ter incompatibilidades de dados também. Um número inteiro que nunca mudará durante a vida do registro é uma escolha muito mais segura do ponto de vista da integridade dos dados, bem como do ponto de vista do desempenho. As chaves naturais geralmente não são tão boas para a manutenção dos dados.

Também quero salientar que o melhor dos dois mundos é usar uma chave de incremento automático (ou, em alguns casos especializados, um GUID) como PK e, em seguida, colocar um índice exclusivo na chave natural. Você obtém as junções mais rápidas, não obtém registros duplicados e não precisa atualizar um milhão de registros filhos porque o nome de uma empresa foi alterado.

Não importa o que você usa como chave primária, desde que seja ÚNICA. Se você se preocupa com a velocidade ou com um bom design de database, use o int, a menos que planeje replicar os dados e use um GUID.

Se este é um database de access ou algum aplicativo minúsculo, então quem realmente se importa. Eu acho que a razão pela qual a maioria de nós desenvolvedores tapa o velho int ou guid na frente é porque os projetos têm uma maneira de crescer em nós, e você quer deixar a opção de crescer.

Muitas variables. Depende do tamanho da tabela, dos índices, da natureza do domínio da chave de string …

Geralmente , os inteiros serão mais rápidos. Mas a diferença será grande o suficiente para se importar? É difícil dizer.

Além disso, qual é a sua motivação para escolher strings? As teclas numéricas de incremento automático costumam ser muito mais fáceis também. É semântica? Conveniência? Replicação / preocupações desconectadas? Sua resposta aqui pode limitar suas opções. Isso também traz à mente uma terceira opção “híbrida” que você está esquecendo: Guids.

Não se preocupe com o desempenho até obter um design simples e de som que esteja de acordo com o assunto que os dados descrevem e que se ajustem bem ao uso pretendido dos dados. Então, se surgirem problemas de desempenho, você pode lidar com eles ajustando o sistema.

Neste caso, é quase sempre melhor usar uma string como chave primária natural, desde que você possa confiar nela. Não se preocupe se for uma string, contanto que a string seja razoavelmente curta, digamos cerca de 25 caracteres no máximo. Você não pagará um preço alto em termos de desempenho.

As pessoas de input de dados ou fonts de dados automáticas sempre fornecem um valor para a suposta chave natural ou às vezes são omitidas? É ocasionalmente errado nos dados de input? Em caso afirmativo, como os erros são detectados e corrigidos?

Os programadores e usuários interativos que especificam consultas podem usar a chave natural para obter o que desejam?

Se você não pode confiar na chave natural, invente um substituto. Se você inventar um substituto, você pode também inventar um inteiro. Então você tem que se preocupar em ocultar o substituto da comunidade de usuários. Alguns desenvolvedores que não ocultaram a chave substituta se arrependeram.

Sim, mas a menos que você espere ter milhões de linhas, não usar uma chave baseada em string porque ela é mais lenta geralmente é uma “otimização prematura”. Afinal, as strings são armazenadas como números grandes, enquanto as teclas numéricas são geralmente armazenadas como números menores.

Uma coisa a observar, no entanto, é se você tiver índices agrupados em uma chave qualquer e estiver fazendo um grande número de inserções que não são sequenciais no índice. Cada linha escrita fará com que o índice reescreva. Se você estiver fazendo inserções em lote, isso pode realmente atrasar o processo.

Índices implicam muitas comparações.

Normalmente, as strings são mais longas do que os inteiros e as regras de collation podem ser aplicadas para comparação, portanto, comparar strings geralmente é uma tarefa computacionalmente mais intensiva do que a comparação de inteiros.

Às vezes, porém, é mais rápido usar uma string como chave primária do que fazer uma junit extra com uma string to numerical id tabela de string to numerical id .

Dois motivos para usar inteiros para colunas PK:

  1. Podemos definir identidade para um campo inteiro que foi incrementado automaticamente.

  2. Quando criamos PKs, o database cria um índice (Cluster ou Non Cluster) que classifica os dados antes de serem armazenados na tabela. Usando uma identidade em uma PK, o otimizador não precisa verificar a ordem de sorting antes de salvar um registro. Isso melhora o desempenho em grandes tabelas.

Qual é a sua razão para ter uma string como chave primária?

Gostaria apenas de definir a chave primária para um campo inteiro de incremento automático e colocar um índice no campo de seqüência de caracteres.

Dessa forma, se você fizer pesquisas na tabela, elas deverão ser relativamente rápidas, e todas as suas associações e pesquisas normais não serão afetadas em sua velocidade.

Você também pode controlar a quantidade do campo de string que é indexado. Em outras palavras, você pode dizer “indexe apenas os 5 primeiros caracteres” se achar que isso será suficiente. Ou, se seus dados puderem ser relativamente semelhantes, você poderá indexar todo o campo.

Do ponto de vista do desempenho – Sim cadeia (PK) irá diminuir o desempenho quando comparado ao desempenho alcançado usando um inteiro (PK), onde PK —> Primary Key.

Do ponto de vista da exigência – Embora esta não é uma parte da sua pergunta ainda gostaria de mencionar. Quando estamos lidando com dados enormes em diferentes tabelas, geralmente procuramos pelo conjunto provável de chaves que podem ser definidas para uma tabela específica. Isto é principalmente porque existem muitas tabelas e principalmente cada uma ou alguma tabela seria relacionada à outra através de alguma relação (um conceito de Chave Estrangeira). Portanto, nem sempre podemos escolher um inteiro como Chave Primária, em vez disso, escolhemos uma combinação de 3, 4 ou 5 atributos como chave primária para essas tabelas. E essas chaves podem ser usadas como uma chave estrangeira quando relacionaríamos os registros com alguma outra tabela. Isso torna útil relacionar os registros em diferentes tabelas quando necessário.

Portanto, para uso ótimo – sempre fazemos uma combinação de 1 ou 2 inteiros com 1 ou 2 atributos de string, mas novamente somente se for necessário.

Pode haver um grande mal-entendido relacionado à cadeia no database. Quase todos pensaram que a representação de números de database é mais compacta do que para strings. Eles acham que em números db-s são representados como na memory. MAS não é verdade. Na maioria dos casos, a representação numérica é mais próxima de uma representação como uma string de outra.

A velocidade de usar o número ou a string depende mais da indexação do que do próprio tipo.

Por padrão ASPNetUserIds são 128 caracteres e o desempenho é bom.

Se a chave tiver que ser única na tabela, deve ser a chave. Aqui está o porquê;

chave de seqüência de caracteres primária = Corrigir relações de database, 1 chave de seqüência de caracteres (O primário) e 1 cadeia de caracteres Índice (A Primária).

A outra opção é uma chave int típica, mas se a string tiver que ser única, você provavelmente precisará adicionar um índice por causa de consultas non-stop para validar ou verificar se é único.

Portanto, usando uma chave de identidade int = Relacionamentos de database incorretos, 1 int key (primário), 1 int índice (primário), provavelmente um único seqüência de caracteres de índice e manualmente ter que validar a mesma seqüência não existe (algo como uma verificação de sql talvez ).

Para obter um melhor desempenho usando um int em uma string para a chave primária, quando a string tiver que ser única, teria que ser uma situação muito estranha. Eu sempre preferi usar chaves de string. E como uma boa regra, não desnormalize um database até que você precise .