Áreas de problema potencial em Várias Tabelas bancos de dados SQL

A integridade dos dados está sujeita ao ataque de uma variedade de quartos. Alguns destes problemas surgem apenas em SQL multitable databases- outros pode acontecer mesmo em bancos de dados que contêm apenas uma única tabela. Você deseja reconhecer e minimizar todas estas ameaças potenciais.

dados de entrada Bad

Os documentos-fonte ou arquivos de dados que você usa para preencher o banco de dados pode conter dados errados. Estes dados podem ser uma versão corrompida de os dados corretos, ou ele pode não ser os dados que deseja. UMA verificação de intervalo informa se os dados tem a integridade de domínio.

Este tipo de verificar as capturas alguns - mas não todos - problemas. Por exemplo, valores incorretos de campo que estão dentro do intervalo aceitável - mas ainda incorreto - não são identificados como problemas.

O uso indevido

Os dados de origem pode estar correto, mas o operador de entrada de dados de forma incorrecta pode transcrever os dados. Este tipo de erro pode levar aos mesmos tipos de problemas como dados de entrada errados. Algumas das soluções são a mesma, também. cheques de alcance ajudam, mas não são infalíveis. Outra solução consiste em ter um segundo operador validar independentemente de todos os dados.

Esta abordagem é custosa porque a validação independente toma duas vezes o número de pessoas e o dobro do tempo. Mas, em alguns casos em que a integridade dos dados é crítica, o esforço e despesa extra pode ser vale a pena.

Falha mecânica

Se ocorrer uma falha mecânica, como uma falha de disco, os dados na tabela podem ser destruídos. Bons backups são a sua principal defesa contra este problema.

Malícia

Considere a possibilidade de que alguém pode quer para corromper seus dados. Sua primeira linha de defesa é para negar o acesso de banco de dados a qualquer um que pode ter uma intenção maliciosa e restringir os usuários autorizados para que possam acessar apenas os dados de que necessitam. A sua segunda defesa é para manter backups de dados em um local seguro. Reavaliar periodicamente as características de sua instalação de segurança. Sendo um pouco paranóico não dói.

Redundância de dados

Redundância de dados - os mesmos itens de dados surgindo em vários lugares - é um grande problema com o modelo hierárquico, mas o problema pode praga bancos de dados relacionais, também. Não só como espaço de armazenamento de resíduos de redundância e desacelerar o processamento, mas também pode levar à corrupção de dados grave.

Se você armazenar o mesmo item de dados em duas tabelas diferentes em um banco de dados, o item em uma dessas tabelas podem mudar enquanto o item correspondente na outra tabela permanece a mesma. Esta situação gera uma discrepância, e você pode ter nenhuma maneira de determinar qual versão está correta. Essa é uma boa razão para manter a redundância de dados ao mínimo.

Apesar de uma certa quantidade de redundância é necessária para a chave primária de uma tabela para servir como uma chave estrangeira em outra, você deve tentar evitar a repetição de todos os itens de dados para além disso.

Depois de eliminar a maior redundância de um projeto de banco de dados, você pode achar que o desempenho é agora inaceitável. Operadores muitas vezes propositadamente usar um pouco de redundância para acelerar o processamento.

Uma prática comum é a concepção inicialmente um banco de dados com pouca redundância e com elevado grau de normalização e, em seguida, depois de descobrir que aplicações importantes executar lentamente, para adicionar seletivamente redundância e desnormalizar. A palavra-chave aqui é selectivamente.

A redundância que você adiciona de volta em deve ter um propósito específico, e porque você está muito consciente tanto da redundância e do perigo que ele representa, você tomar as medidas apropriadas para assegurar que a redundância não causar mais problemas do que resolve.

Quando você exceder a capacidade do seu DBMS

Um sistema de banco de dados pode funcionar adequadamente durante anos e, em seguida, começar a experimentar erros intermitentes que se tornam progressivamente mais graves. Este pode ser um sinal de que você está se aproximando um dos limites de capacidade do sistema. Há, afinal, limites para o número de linhas que uma mesa pode ter. Há também limites em colunas, restrições e vários outros recursos de banco de dados.

Verifique o tamanho atual eo conteúdo do seu banco de dados contra as especificações listadas na documentação de seu DBMS. Se você estiver perto do limite em qualquer área, considere atualizar para um sistema com maior capacidade. Ou você pode querer arquivar dados mais antigos que já não é ativo e, em seguida, excluí-lo do seu banco de dados.