20 dicas para Bancos de Dados

Existe uma lista interminável de boas práticas quando nos referimos a Bancos de Dados. Abaixo listo algumas delas (as que mais utilizo) e, mesmo que algumas delas possam parecer óbvias, vale muito a pena reforçá-las. Vale lembrar que elas se aplicam a qualquer SGBD (Sistema Gerenciador de Banco de Dados):

1) Update sem Where: Vamos começar pela mais crítica de todas. Todas as vezes que for escrever um comando de Update, ligue seu alerta máximo!! Muita atenção aos parâmetros que você indicará no Where para garantir que vão atender sua necessidade e, mais importante ainda, não esqueça de executar o comando com a cláusula Where junto. Principalmente em ambiente de produção. Essa dica vale também para o Delete!!!

2) Modelagem: Embora a ansiedade por sair fazendo seja maior que qualquer coisa, planejar (e planejar bem) diminuem muito o tempo de retrabalho. Pode parecer cansativo debruçar sobre um modelo entidade-relacionamento mas posso garantir que este é um tempo muito bem investido.

3) Comentários: nossas criações não são nossas para sempre. Use e abuse de comentários explicando todos os pontos do seu modelo. Isso facilita muito a manutenção e melhoria dos seus bancos e scripts, seja por outras pessoas, ou até mesmo por você no futuro.

4) Chaves-Primárias / Chaves-Estrangeiras: Como alguém pode criar uma tabela sem chaves primárias ou estrangeiras? Sim, eles podem. E fazem. Criar chaves em uma tabela é imprescindível e pode garantir não só o bom desempenho mas a integridade das informações.

5) Log: Aquele que nunca precisou de uma informação sobre uma alteração ou exclusão em uma tabela que atire a primeira pedra. Tabelas de log e de histórico são componentes muito úteis em qualquer sistema. Procure criar estruturas capazes de armazenar fatos importantes para auxiliar em pesquisas futuras.

6) Arquivo morto: Alguns sistemas geram muitas informações e nem sempre os dados mais antigos podem ser desprezados. Elaborar uma forma de segregar os dados antigos e os atuais é uma forma simples de garantir um bom desempenho do seu banco. Obviamente essa decisão depende também do desenvolvimento do próprio aplicativo, mas como boa parte do funcionamento do aplicativo é moldado pela construção do seu banco de dados, esse é um bom momento para tentar plantar essa "sementinha" junto aos desenvolvedores.

7) Índices para colunas muito utilizadas (SELECT): Muitas colunas não fazem parte das chaves principais das suas tabelas mas são amplamente utilizadas em comandos de pesquisa (Where, Join, Top e Order By, por exemplo). Se este é o seu caso, estude criar índices para esses campos. Isso vai agilizar muito o resultado das consultas.

8) Índices para colunas muito utilizadas (INSERT, UPDATE, DELETE): Essa dica vem logo na sequência pois mostra o oposto do que indicamos acima. Índices para campos que sofrem uma atualização absurda pelas operações de manutenção de dados precisam ser muito bem pensados. A constante alteração gera a constante manutenção dos índices, o que piora o desempenho da tabela. Por isso sua criação precisa ser muito bem analisada.

9) Monitoramento das consultas: Seu sistema está criado e funcionando. É hora de partir para um novo desafio. Sim, mas nem por isso o sistema atual deve ser deixado de lado. Consultas devem ser monitoradas com frequência para garantir a manutenção do seu desempenho. Algumas consultas muito eficientes no início podem apresentar desempenho ruim com o passar do tempo por conta do volume de informações tratados por ela. Nesse momento, uma intervenção pode ser crucial para que o sistema continue rodando de forma satisfatória.

10) "Values" múltiplos: Se você precisa inserir vários registros de uma só vez utilizando o comando Insert, opte por passá-los de uma só vez, sequencialmente:

INSERT INTO TAB_TESTE (CAMPO1, CAMPO2)
VALUES (1, 'Info1'),
                 (2, 'Info2'),
                 (3, 'Info3')

11) Cultura, idioma e linguagem: O ideal é que o banco de dados utilizado pela aplicação esteja configurado em relação à idioma/cultura compatível com as regras de negócio ou contexto do sistema para evitar ter que realizar conversões explícitas nas consultas de banco de dados, gerando prejuízo à performance.

12) Order By e Distinct: Use com moderação. Estes são dois itens que exigem muito do seu banco e podem atrapalhar muito no desempenho.

13) Variáveis e Parâmetros: Procure trabalhar com variáveis e parâmetros onde os tipos de dados respeitam fielmente os campos das tabelas aos quais se referem. Isso evita conversões desnecessárias.

14) Select: É muito tentador simplesmente executar um "Select *" nas tabelas e depois utilizar apenas os campos desejados. Este é mais um ponto de esforço desnecessário imposto ao seu banco. Procure trazer, já de início, apenas o que vai utilizar. Seu banco agradece.

15) Cache: Para dados que quase não sofrem atualizações, colocar esses dados em cache pode viabilizar um bom desempenho. Porém, verifique a viabilidade dessa aplicação para cada projeto.

16) Tipos de Dados: Se preocupe sempre com os tipos das colunas das tabelas do sistema que você está criando para verificar se os mesmos correspondem fielmente ao tipo de informação que será armazenada. Criar tipos genéricos como uma coluna de data ou valor total como Varchar() permitirá que qualquer tipo de dado seja salvo, gerando prejuízos futuros. Tipos de dados são importantes!!!

17) Orientação à Objetos: A base de dados deve ser projetada e modelada segundo boas práticas de banco de dados e não boas práticas de orientação a objetos.

18) Views e Procedures: Quando o código a ser executado encontra-se em uma procedure ou view, o banco de dados não precisa fazer verificações e validações, pois as mesmas já foram feitas ao ser criar as procedures e views. Portanto, com o banco de dados poupando este trabalho, logicamente a perfomance das execuções de SQL enviados pela aplicação aumenta consideravelmente em sistemas críticos.

19) Having: Caso necessite filtrar dados em um agrupamento de informações, prefira sempre realizar esta operação na cláusula WHERE ao invés do HAVING, por questões de performance, a não ser que seja necessário realizar algum filtro utilizando realmente as operações de agregação. Exemplo:

--Evite
SELECT ID, Idade
FROM Tab_Teste A
GROUP BY ID, Idade
HAVING Idade = 2

--Recomendável
SELECT ID, Idade
FROM Tab_Teste A
WHERE Idade = 2
GROUP BY ID, Idade

20) Flags ou Booleanos: Caso tenha necessidade de possuir colunas em uma tabela cujo valor se refira à valores verdadeiros e falsos, como por exemplo, especificar se um registro está ativo ou não na sua tabela, opte por criar as colunas com o tipo booleano nativo da base dados específico que você está utilizando, ao invés de utilizar informações ‘S’ ou ’N’ em um campo do tipo texto. Em tabelas com muitos registros, o filtros por estes campos torna-se desnecessariamente lento.

Que estas dicas possam auxiliar na melhora de perfomance dos bancos criados e utilizados por vocês.

Estamos aqui à disposição para auxiliá-los na criação, configuração e manutenção do seu banco de dados. Entre em contato.

Um grande abraço à todos.

#microsoft #power #mercadodetrabalho #powerbi #design #carreira #treinamentos #protheus #besimpleconsulting #sqlserver #sql #totvs #cursos #cursosonline #migração #inovação #software #data #cloud #erpsoftware #estrategiaempresarial #reestruturação #performance #projetos