Passa muitas vezes despercebido aos mais incautos. Mesmo que tenhamos uma query em que explicitamente colocamos uma coluna not null, o select into vai deixar a definição da coluna nullable. Mas porque é que isso interessa? Interessa porque sabemos que é muito mais do que um preciosismo definirmos o nosso modelo de dados como deve de ser. Há muitas maneiras de o SQL Server melhorar um plano...
Eu sei que posso já ser considerado da “velha guarda”. Aprendi a programar com 11 anos, há mais anos do que muitos colegas meus têm de vida. Se calhar é por isso gosto de ver coisas feitas à moda antiga. Uma delas é ver todos os declare no topo do script. E de repente: Mas assim apenas declaro mais abaixo e só aí vou usar o espaço...
Há erros que nunca cometemos. Por exemplo, um overflow num int que nos faz pensar por que raio é que a coluna não foi logo definida como bigint. Ou um destes casos que quero mostrar agora. Porque nunca acontecem. Sabemos que se tentarmos ultrapassar certos limites, o SQL Server nos avisa. Ou este Mas há outros… Vamos correr de novo para vermos os tamanhos reais em bytes...
Conversa interessante com um colega de profissão, estamos a discutir um caso em que anda um bug à solta e de repente digo-lhe: “Mas nem sempre um TRY/CATCH funciona como estás à espera, por vezes há erro dentro do código no TRY e não salta para o CATCH”. Sim, há quem não acredite. Mas acontece. E até está bem documentado. Vamos ver um desses casos para dissiparmos...
Há poucos dias fiz um post sobre como nem sempre um índice ajuda em updates e deletes. Para situar quem não o leu, mostrei que um índice que à primeira vista pode ajudar nem sempre o faz. Por vezes até se revela desastroso em termos de performance. Mas como há sempre quem diga que “não cobriste todos os casos, se tivesses __________ seria diferente”. E ainda bem...
O meu post de há algum tempo sobre o tamanho das variáveis e o memory grant deu algo que falar, por isso resolvi, ao estilo de Hollywood destes últimos anos, revisitá-lo. Se se lembram desse post (também não foi há assim tanto tempo…) a questão era: O tamanho das variaveis não interessa, se eu colocar um varchar(max) ou varchar(50) é igual porque o SQL Server só usa...
E se, de repente, ouvirem uma coisa destas? A quantidade de colunas não importa num select, não estou a agregar nem ordenar a saída. Pois, e eu já acreditei no Pai Natal, mas já foi há algum tempo. Vamos criar umas tabelas para testar esta ideia? Podemos agora correr este pedacinho de código? Nada de estranho se passa, como esperado. Mas no fundo o que queríamos era...
Com o tempo vêm-se coisas muito giras e assunções muito elaboradas. Já me ouviram dizer que a Assunção é a mãe de todas as trapalhadas? Temos um “delete que demora muito tempo”. Normalmente é um delete “à bruta”, todo feito de uma vez em que vemos o nosso log a crescer até ao infinito e mais além. Ou temos um update a uma certa coluna e resolvemos...
Há uns dias coloquei aqui um post sobre eliminação de joins e, sem querer, deparei-me hoje com uma situação onde parecia que o SQL Server não estava a fazer um bom trabalho. Vai-se a ver… e quem não estava a fazer um bom trabalho éramos nós. A situação era bem mais complicada do que esta, mas se pegarmos no código do último post é rápida de explicar....
Há alguns dias em conversa com um colega referi o termo “join elimination” e ele ficou um pouco surpreendido. Importa referir que a especialidade dele não é SQL e que é fenomenal em coisas que eu pouco entendo também. A famosa máxima “todos somos ignorantes, apenas em coisas diferentes”. Vamos ver uma das maneiras mais simples de join elimination que o SQL Server trata com muito carinho....