Sempre que você, como desenvolvedor, recebe uma tarefa com base no código existente, você tem que enfrentar muitos desafios. Um desses desafios - na maioria das vezes o mais exigente - envolve a compreensão do modelo de dados de um aplicativo.

Você normalmente se depara com tabelas, visualizações, colunas, valores, procedimentos armazenados, funções, restrições e gatilhos confusos que demoram muito para fazer sentido para você. E, uma vez que o façam, você começa a perceber muitas maneiras de melhorar e aproveitar as informações armazenadas.

Se você for um desenvolvedor experiente, provavelmente também notará coisas que poderiam ter sido feitas melhor no início, ou seja, falhas de design.

Neste artigo, você aprenderá sobre algumas das más práticas comuns de design de banco de dados, por que são ruins e como você pode evitá-las.

aprender a codificar c ++

Má prática nº 1: ignorar o propósito dos dados

Os dados são armazenados para serem consumidos posteriormente, e o objetivo é sempre armazená-los e recuperá-los da maneira mais eficiente. Para conseguir isso, o projetista do banco de dados deve saber com antecedência o que os dados representarão, como serão adquiridos e a que taxa, qual será o seu volume operacional (ou seja, quantos dados são esperados) e, finalmente , como será usado.

Por exemplo, um sistema de informação industrial onde os dados são coletados manualmente todos os dias não terá o mesmo modelo de dados que um sistema industrial onde as informações são geradas em tempo real. Por quê? Porque é muito diferente lidar com algumas centenas ou milhares de registros por mês em comparação com gerenciando milhões deles no mesmo período. Considerações especiais devem ser feitas pelos designers a fim de manter a eficiência e usabilidade do banco de dados, se os volumes de dados forem grandes.

Mas, é claro, o volume de dados não é o único aspecto a ser considerado, uma vez que o propósito dos dados também afeta o nível de normalização, a estrutura de dados, o tamanho do registro e a implementação geral de todo o sistema.

Portanto, conhecer completamente o propósito do sistema de dados que você criará leva a considerações na escolha do mecanismo de banco de dados, as entidades a serem projetadas, o tamanho e o formato do registro e as políticas de gerenciamento do mecanismo de banco de dados.

Ignorar essas metas levará a projetos com falhas básicas, embora estrutural e matematicamente corretos.

ajuste de desempenho no sql server 2008

Má prática nº 2: Normalização pobre

Projetar um banco de dados não é uma tarefa determinística; dois designers de banco de dados podem seguir todas as regras e princípios de normalização para um determinado problema e, na maioria dos casos, gerarão layouts de dados diferentes. Isso é inerente à natureza criativa da engenharia de software. No entanto, existem algumas técnicas de análise que fazem sentido em todas as instâncias, e segui-las é a melhor maneira de chegar a um banco de dados com o melhor desempenho.

Apesar disso, frequentemente nos deparamos com bancos de dados que foram projetados dinamicamente, sem seguir as regras mais básicas de normalização. Devemos deixar claro que: Todo banco de dados deve, pelo menos, ser normalizado para a terceira forma normal, pois é o layout que melhor representará suas entidades, e cujo desempenho será mais equilibrado entre consultar e inserir-atualizar-excluir registros .

Se você tropeçar com tabelas que não estão em conformidade com 3NF , 2NF, ou mesmo 1NF, considere redesenhar essas tabelas. O esforço que você investe para fazer isso terá retorno no curtíssimo prazo.

Má prática nº 3: redundância

Muito relacionado ao ponto anterior, já que um dos objetivos de normalização é para reduzi-lo, redundância é outra prática ruim que aparece com bastante frequência.

Campos e tabelas redundantes são um pesadelo para os desenvolvedores, pois exigem lógica de negócios para manter muitas versões das mesmas informações atualizadas. Essa é uma sobrecarga que pode ser evitada se as regras de normalização forem seguidas completamente. Embora às vezes a redundância possa parecer necessária, ela deve ser usada apenas em casos muito específicos e ser claramente documentada para ser levada em consideração em desenvolvimentos futuros.

Os efeitos negativos típicos da redundância são um aumento desnecessário do tamanho do banco de dados, os dados sendo propensos a inconsistência e diminuições na eficiência do banco de dados, mas - mais importante - pode levar à corrupção de dados.

Má prática nº 4: Má integridade referencial (restrições)

A integridade referencial é uma das ferramentas mais valiosas que os mecanismos de banco de dados fornecem para manter a qualidade dos dados no seu melhor. Se nenhuma restrição ou muito poucas restrições forem implementadas desde o estágio de design, a integridade dos dados terá que depender inteiramente da lógica de negócios, tornando-a suscetível a erro humano.

como é o c ++?

Má prática nº 5: não tirar proveito dos recursos do DB Engine

Quando você está usando um motor de banco de dados (DBE), você tem um software poderoso para suas tarefas de tratamento de dados que simplificará o desenvolvimento de software e garantirá que as informações estejam sempre corretas, seguras e utilizáveis. Um DBE fornece serviços como:

• Exibições que fornecem uma maneira rápida e eficiente de examinar seus dados, normalmente desnormalizando-os para fins de consulta sem perder a exatidão dos dados.
• Índices que ajudam a acelerar as consultas nas tabelas.
• Funções agregadas que ajudam a analisar informações sem programação.
• Transações ou blocos de sentenças que alteram dados que são todas executadas e confirmadas ou canceladas (revertidas) se algo inesperado ocorrer, mantendo assim as informações em um estado perpetuamente correto.
• Bloqueios que mantêm os dados seguros e corretos enquanto as transações estão sendo executadas.
• Procedimentos armazenados que fornecem recursos de programação para permitir tarefas complexas de gerenciamento de dados.
• Funções que permitem cálculos sofisticados e transformações de dados.
• Restrições que ajudam a garantir a exatidão dos dados e evitar erros.
• Gatilhos que ajudam a automatizar ações quando ocorrem eventos nos dados.
• Otimizador de comandos (planejador de execução) que é executado nos bastidores, garantindo que cada frase seja executada da melhor forma e mantendo os planos de execução para ocasiões futuras. Este é um dos melhores motivos para utilizar views, stored procedures e functions, já que seus planos de execução são mantidos permanentemente no DBE.

Não conhecer ou ignorar esses recursos levará o desenvolvimento a um caminho extremamente incerto e certamente a bugs e problemas futuros.

Má prática nº 6: Chaves primárias compostas

Esse é um ponto meio controverso, já que muitos projetistas de banco de dados falam hoje em dia sobre o uso de um campo gerado automaticamente com ID de inteiro como a chave primária em vez de um composto definido pela combinação de dois ou mais campos. Isso é atualmente definido como a “melhor prática” e, pessoalmente, tendo a concordar com isso.

jwt rejeitou autenticação de usuário falhou

No entanto, esta é apenas uma convenção e, claro, DBEs permitem a definição de primário composto chaves, que muitos designers consideram inevitáveis. Portanto, como ocorre com a redundância, as chaves primárias compostas são uma decisão de design.

Cuidado, porém, se sua tabela com uma chave primária composta deve ter milhões de linhas, o índice que controla a chave composta pode crescer até um ponto onde o desempenho da operação CRUD é muito degradado. Nesse caso, é muito melhor usar uma chave primária de ID de inteiro simples cujo índice será compacto o suficiente e estabelecerá as restrições DBE necessárias para manter a exclusividade.

Má prática nº 7: má indexação

Às vezes, você terá uma tabela que precisa consultar por muitas colunas. Conforme a tabela cresce, você notará que os SELECTs nessas colunas ficam mais lentos. Se a tabela for grande o suficiente, você pensará, logicamente, em criar um índice em cada coluna que usar para acessar essa tabela apenas para descobrir quase imediatamente que o desempenho de SELECTs melhora, mas os INSERTs, UPDATEs e DELETEs são eliminados. Isso, é claro, se deve ao fato de que os índices devem ser mantidos sincronizados com a tabela, o que significa sobrecarga massiva para o DBE. Este é um caso típico de indexação excessiva que pode ser resolvido de várias maneiras; por exemplo, tendo apenas um índice em todas as colunas diferente da chave primária que você usa para consultar a tabela, ordenar essas colunas da mais usada para a menos usada pode oferecer melhor desempenho em todas as operações CRUD do que um índice por coluna.

Por outro lado, ter uma tabela sem índice nas colunas que são usadas para consultá-la irá, como todos sabemos, levar a um desempenho ruim em SELECTs.

Além disso, a eficiência do índice às vezes depende do tipo de coluna; índices em colunas INT mostram o melhor desempenho possível, mas índices em VARCHAR, DATE ou DECIMAL (se isso fizer sentido) não são tão eficientes. Essa consideração pode até mesmo levar ao redesenho de tabelas que precisam ser acessadas com a melhor eficiência possível.

Portanto, a indexação é sempre uma decisão delicada, já que indexar em excesso pode ser tão ruim quanto falta e porque o tipo de dados das colunas a serem indexadas tem uma grande influência no resultado final.

Má prática nº 8: convenções de nomenclatura inadequadas

Isso é algo com que os programadores sempre lutam quando se deparam com um banco de dados existente: entender quais informações estão armazenadas nele pelos nomes de tabelas e colunas porque, muitas vezes, não há outra maneira.

quem é menos capaz de reconhecer a gestalt?

O nome da tabela deve descrever qual entidade ela contém, e cada nome de coluna deve descrever quais informações ela representa. Isso é fácil, mas começa a ser complicado quando as tabelas precisam se relacionar. Os nomes começam a ficar confusos e, pior, se houver convenções de nomenclatura confusas com normas ilógicas (como, por exemplo, “o nome da coluna deve ter 8 caracteres ou menos”). A consequência final é que o banco de dados se torna ilegível.

Portanto, um convenção de nomes é sempre necessário se se espera que o banco de dados dure e evolua com o aplicativo que suporta, e aqui estão algumas diretrizes para estabelecer um sucinto, simples e legível:

• Sem limitações no tamanho do nome da tabela ou coluna. É melhor ter um nome descritivo do que uma sigla que ninguém se lembra ou entende.
• Nomes iguais têm o mesmo significado. Evite campos com o mesmo nome, mas com tipos ou significados diferentes; isso vai ser confuso mais cedo ou mais tarde.
• A menos que necessário, não seja redundante. Por exemplo, na tabela “Item,” não há necessidade de colunas como “ItemName,” “PriceOfItem,” ou nomes semelhantes; “Nome” e “Preço” são suficientes.
• Cuidado com as palavras reservadas do DBE. Se uma coluna deve ser chamada de 'Índice', que é uma palavra reservada do SQL, tente usar uma outra diferente, como 'Número do índice'.
• Se seguir a regra de chave primária simples (número inteiro gerado automaticamente), nomeie-o como “Id” em todas as tabelas.
• Se ingressar em outra tabela, defina a chave estrangeira necessária como um número inteiro, denominado 'Id' seguido pelo nome da tabela associada (por exemplo, IdItem).
• Se houver restrições de nomenclatura, use um prefixo que descreva a restrição (por exemplo, 'PK' ou 'FK'), seguido pelo nome da tabela ou tabelas envolvidas. Claro, usar sublinhados (“_”) com moderação ajuda a tornar as coisas mais legíveis.
• Para nomear índices, use o prefixo “IDX” seguido do nome da tabela e a coluna ou colunas do índice. Além disso, use “UNIQUE” como prefixo ou sufixo se o índice for exclusivo e sublinhado quando necessário.

Existem muitas diretrizes de nomenclatura de banco de dados na Internet que irão iluminar mais esse aspecto muito importante do design de banco de dados, mas com essas diretrizes básicas, você pode pelo menos obter um banco de dados legível. O que é importante aqui não é o tamanho ou a complexidade de suas diretrizes de nomenclatura, mas sua consistência em segui-las!

Algumas Observações Finais

O design de banco de dados é uma combinação de conhecimento e experiência; a indústria de software evoluiu muito desde seus primeiros dias. Felizmente, existe conhecimento suficiente disponível para ajudar designers de banco de dados alcançar os melhores resultados.

Há um bom design de banco de dados diretrizes em toda a internet, bem como más práticas e coisas para evitar no design de banco de dados. Basta fazer sua escolha e cumpri-la.

E, não se esqueça, é apenas por meio de experimentação, erros e sucessos que você aprende, então vá em frente e comece agora.