Sua empresa está gastando muito com bancos de dados? O desempenho não está satisfatório? Caso suas respostas sejam afirmativas, fique tranquilo (mas nem tanto) – você não está sozinho e o objetivo desse livro é te ajudar a superar essas dificuldades.
 | Os custos com infraestrutura para sustentar bancos de dados são inversamente proporcionais ao conhecimento daqueles que os administram. |
Para quem entende pouco sobre bancos de dados, a solução mais simples, quando eles se convertem em gargalos, é “aumentar” a infraestrutura. Literalmente, isso é dinheiro deixado na mesa, corroendo a lucratividade e consequentemente a competitividade das organizações.
“Enganos” comuns que você não cometerá mais
Existem alguns “enganos” absolutamente comuns, fáceis de evitar, que impactam negativamente o desempenho dos bancos de dados. Talvez, sem perceber, você os cometa no seu dia-a-dia. Após concluir a leitura desse livro, entenderá quais os detalhes que realmente fazem o diferencial para que o banco de dados não se torne um problema futuro para o negócio.
Índices pouco assertivos
Acredite, seu banco de dados dará respostas muito mais rápidas se os “índices corretos” estiverem sido implementados!
| Muitos índices, maior custo com gravações. Poucos índices, performance pobre em leituras. |
São os índices, quando definidos do jeito certo, que garantem eficiência e estabilidade, independente do volume de dados.
Conversões dos tipos de dados pela consulta
Utilizar tipos de dados, diferentes do originalmente definido na coluna, principalmente na cláusula where, geralmente faz com que toda tabela tenha que ser lida. Afinal, antes é preciso aplicar a conversão para cada linha da tabela, para então recuperar somente os registros necessários. O mesmo se aplica para o uso de funções em campos da tabela, na cláusula where. É preciso conhecer o resultado da expressão, processando-a em cada linha da tabela, para poder utilizá-la posteriormente.
| O “banco de dados” faz o que você pedir, da melhor forma possível. Não é culpa do SGBD se os pedidos são feitos da forma errada. |
Obtenção de mais dados do que o necessário
Outro “engano” muito comum no desenvolvimento de aplicações que acessam banco de dados, é solicitar um grande volume de informações, trafegá-las via rede, para que somente então a aplicação utilize algum filtro nesses dados, no momento de processá-los.
| O uso indevido de ferramentas ORM é causa comum para tráfego exagerado de dados. |
Processamento row-by-row
O mindset de desenvolvedor geralmente produz consultas semanticamente corretas, mas ineficientes, envolvendo loops e condicionais.
Boas consultas exigem mindset de DBA, procurando tratar dados em blocos (set-based).
| É muito mais rápido, para o banco de dados, efetuar um update em 1.000 linhas de uma única vez, do que 1.000 updates independentes. Abordagens set-based possibilitam isso em cenários pouco intuitivos para desenvolvedores. |
 | Set-based design: uma introdução Nesse vídeo compartilhamos uma visão prática de como a abordagem set-based possibilita implementar consultas com melhor desempenho. |
Lembre-se: o banco de dados é importante para os negócios
Bancos de dados influenciam nos resultados dos negócios muito além dos custos com infraestrutura e licenciamento.
Bancos de dados lentos repercutem em aplicações lentas, que atrapalham o “negócio”. Lentidão prejudica a experiência dos usuários e, em muitos casos, acaba impactando diretamente nos resultados financeiros das organizações. No varejo on-line, por exemplo, estima-se que cada segundo para renderizar uma página implique em perda de até 7% das conversões. Por outro lado, bancos de dados performáticos impactam positivamente no desempenho das aplicações.
| Em um mundo cada vez mais data-centric, onde volumes cada vez maiores de dados são gerados dia-a-dia e, idealmente, fundamentam as tomadas de decisão, bancos de dados convertem-se em ativo estratégico. |
Bancos de dados, que lidam com volumes de dados imensos, necessitam estar devidamente otimizados, para que de fato, possam fazer a diferença. Utilizá-los apenas como repositórios dos dados, não dando sua devida importância, irá torná-lo o vilão em potencial de qualquer aplicação. Sendo assim, é vital para qualquer negócio evitar que o banco de dados venha a ser o ponto central do gargalo, principalmente quando se almeja um crescimento constante com o passar do tempo.
Estudar SQL Server, Oracle, PostgreSQL? Tanto faz!
Embora cada SGBD tenha suas especificidades e particularidades, boa parte, senão a maioria dos conceitos mais relevantes, são comuns a todos. Índices, por exemplo, seguem princípios relativamente comuns entre eles.
Há alguns anos SQL tem sido suportada por todos os SGBDs de maneira cada vez mais uniforme, conforme a especificação ANSI. Entretanto, ainda que existam notáveis extensões visando suportar especificidades e recursos exclusivos.
SQL (Structured Query Language)
SQL (Structured Query Language) está formalmente definida na ISO 9075, com última revisão formal disponibilizada em 2016. Trata-se de um padrão de fato.
Finalmente, a tipagem de dados nos diversos SGBDs é bem similar. Isso significa que a modelagem de dados para um SGBD deve funcionar para os demais, com impacto próximo do zero.
O que precisa para “acompanhar” este livro
Qualquer SGBD serve! Mas, nesse livro utilizaremos SQL Server.
Pode ser utilizado a distribuição Developer, disponibilizada pela Microsoft para quem deseja estudar, de forma gratuita. Essa versão possui todos os recursos da versão Enterprise, mas não deve ser utilizada em ambiente produtivo.
Como cliente, utilizaremos o Microsoft Management Studio, com dois add-ins gratuítos.
- SQL Sentry Plan Explorer da SentryOne: ferramenta que estende os recursos do plano de execução do Management Studio e que facilita algumas análises.
- dbForge SQL Complete da Devart: ferramenta que tem vários facilitadores para escrita de código SQL, sendo um deles o de formatação do código (que pode ser customizável), além de um intellisense mais intuitivo que o nativo.
Para pensar…
Sabe o que mais, além dos bancos de dados, representa uma grande restrição para o desenvolvimento de aplicações com bom desempenho? Dinheiro, ou melhor, a falta dele!
Consultas lentas, aplicações lentas, custos elevados e resultados pobres! Você não precisa disso e vamos te mostrar como usar SQL do jeito certo nos próximos capítulos.
