Início / dba / Perguntas / 56245
Accepted
Matthew Verstraete
Asked: 2014-01-07 16:59:14 +0800 CST

É melhor começar com tipos INT menores e crescer conforme necessário?

  • 772

Estou projetando um novo banco de dados SQL para meu aplicativo da Web ASP.net e posso prever que algumas das colunas de ID ficarão muito grandes na necessidade de recursos INT, BIGINTmas isso não acontecerá por alguns anos. Com o Entity Framework no ASP.net, é bastante fácil alterar os tipos de dados da coluna. Então, eu queria saber, do ponto de vista do design e do ponto de desempenho, é melhor começar usando os tipos de colunas menores, como TINYINTe SMALLINTe crescer, INTe BIGINTquando finalmente chegar a hora?

database-design

3 respostas

  1. Best Answer

    Eu sugeriria o tamanho certo de suas colunas desde o início. Você precisa levar em consideração o crescimento esperado dos dados versus a vida útil do aplicativo. Se levar 100 anos para que seus dados inteiros exijam um tipo de dados INT, provavelmente você pode ficar com um SMALLINT se achar que seu aplicativo provavelmente não durará tanto. Se levar apenas alguns anos para chegar lá, seria mais fácil lidar com isso agora, em vez de arriscar uma falha no aplicativo quando o limite superior de SMALLINT for atingido ou correr o risco de esquecer de corrigi-lo quando estiver próximo.

    Caso contrário, seu aplicativo provavelmente falhará em algum momento, provavelmente no meio da noite ou quando você menos esperar! Ou falhará para outra pessoa encarregada de manter seu aplicativo.

    Se os usuários podem conviver com o fato de seu aplicativo estar inativo enquanto você determina que seu tipo de dados excedeu seu tamanho e toma medidas para corrigi-lo, então você pode esperar. Aposto que esse não é um cenário aceitável e você gostaria de manter o tempo de funcionamento do aplicativo o mais próximo possível de 100%.

    Não espere o "algum dia" chegar, acerte hoje!

    • 6

  2. Em geral, alterar o tipo de campo pode levar algum tempo - dependendo do tamanho da tabela. Índice também reconstruído nesse caso. Em grandes tabelas com milhões de registros, o processo pode demorar um pouco. Penalidades e overheads de bigints não são tão significativos para complicar as coisas.

    • 2

  3. Sugiro usar o bom senso, não ir longe demais e escolher o tipo de dados certo que satisfaça seus requisitos a longo prazo.

    • Se você planeja começar com tinyint=>, isso sugere que sua(s) mesa(s) não aumentará(ão) tão rapidamente. A propósito, você sabia que int no SQL Server significa até 2 ^ 31 (~ 2 bilhões de linhas) ?!

    • É verdade: alterar os tipos de dados posteriormente pode ser difícil.

    • Além disso, um ponto a se pensar é que o tamanho importa para tabelas grandes, mesmo dizendo que você está economizando 4 bytes por linha (=diferença de armazenamento entre inte bigint), você deve pensar na escala:

      10^7 linhas => 0,038 GB salvo

      10^8 linhas => 0,38 GB salvo

      10^9 linhas => 3,8 GB salvos

    Multiplique isso por x locais onde você pode tomar a decisão de usar um bigint em vez de int e veja os resultados ...

    • Um índice clusterizado amplia os índices não clusterizados
    • 1

relate perguntas