Quando a integridade referencial não é apropriada?

Question

Entendo a necessidade de ter integridade referencial para limitar valores específicos na entrada ou possivelmente impedindo -os de remover mediante solicitação de exclusão. No entanto, não estou claro quanto a um caso de uso válido que excluiria esse mecanismo de sempre ser usado.

Eu acho que isso cairia em várias sub-perguntas:

1. Quando a integridade referencial não é apropriada?
2. É apropriado ter campos contendo vários e/ou possivelmente subconjuntos incompletos da lista de uma chave estrangeira?
3. Normalmente, essa deve ser uma decisão de design de estrutura de esquema ou uma decisão de design de interface? (Ou possivelmente nenhum ou ambos)

Pensamentos?

Answer 1

Quando a integridade referencial não é apropriada?

Integridade referencial se normalmente não usada em data warehouses, onde os dados são uma cópia somente leitura de uma base de dados transacional. Outro exemplo de quando você não precisa do RI é quando deseja registrar informações que incluem IDs de linha; Manter a integridade referencial para uma tabela de log somente leitura é um desperdício de sobrecarga de banco de dados.

É apropriado ter campos contendo vários e/ou possivelmente subconjuntos incompletos da lista de uma chave estrangeira?

Às vezes, você se importa mais com a captura de dados do que a qualidade dos dados. Imagine que você está agregando uma grande quantidade de dados de sistemas díspares que cada um por si só sofre com problemas de qualidade dos dados. Às vezes, você está atrás do bem maior de qualidade dos dados e de ter tudo em um só lugar, mesmo com teclas quebradas, etc. representa um ponto de partida para avançar em direção à verdadeira qualidade dos dados. Não é o ideal, mas acontece, pois os anos de idade podem superar as compensações.

Normalmente, essa deve ser uma decisão de design de estrutura de esquema ou uma decisão de design de interface? (Ou possivelmente nenhum ou ambos)

Tudo sobre o desenvolvimento de sistemas está centrado na segurança da informação e um elemento -chave é a integridade dos dados. A estrutura do banco de dados deve se inclinar para aplicar essas coisas quando possível, no entanto, muitas vezes você não está lidando com os modernos sistemas de banco de dados. Às vezes, sua fonte de dados é uma antiga escola AS400 com aplicativos antiquados há muito tempo. Às vezes, você precisa criar uma camada de dados e negócios que forneça a integridade dos dados.

Apenas meus pensamentos.

Answer 2

O único caso que ouvi falar é se você vai carregar uma grande quantidade de dados no seu banco de dados; Nesse caso, pode fazer sentido desligar a integridade referencial, desde que você saiba com certeza que os dados são válidos. Depois que o seu carregamento/migração estiver concluído, a integridade referencial deve ser ligada novamente.

Existem argumentos sobre como colocar as regras de validação de dados no código de programação versus o banco de dados, e acho que depende dos casos de uso do seu software. Se um único aplicativo for o único caminho para o banco de dados, você poderá colocar a validação no próprio programa e provavelmente ficará bem. Mas se vários programas diferentes estiverem usando o banco de dados ao mesmo tempo (por exemplo, seu aplicativo e o aplicativo de seu amigo), você desejará regras de negócios no banco de dados para que seus dados sejam sempre válidos.

Por 'regras de validação', estou falando de regras como 'itens no carrinho> 0'. Você pode ou não querer regras de validação. Mas acho que as chaves primárias/estrangeiras são sempre importantes (ou você pode encontrar mais adiante que gostaria de tê -las). Eu acho que eles são necessários se você quiser replicação em algum momento.

Answer 3

1. Quando a integridade referencial não é apropriada?

   Às vezes, quando você está copiando muitos registros a granel ou restaurando dados de algum tipo de backup, é conveniente desativar temporariamente as restrições de integridade referencial.

2. É apropriado ter campos contendo vários e/ou possivelmente subconjuntos incompletos da lista de uma chave estrangeira?

   A duplicação de dados dessa maneira vai contra o conceito de normalização. Existem vantagens e desvantagens nessa abordagem.

3. Normalmente, essa deve ser uma decisão de design de estrutura de esquema ou uma decisão de design de interface? (Ou possivelmente nenhum ou ambos)

   Eu consideraria isso uma decisão de design de esquema. Pense na melhor maneira de modelar seu problema em termos relacionais. Use o banco de dados da maneira como foi planejado.

Answer 4

A integridade referencial sempre seria apropriada se não tivesse o custo de desempenho, escalabilidade e/ou outros recursos.

Em alguns aplicativos, a integridade referencial pode ser negociada por algo mais importante que a qualidade dos dados.

Answer 5

1. Nunca, embora algumas pessoas no NoSQL, nos reinos de vários valores e oo-DB pareçam de maneira diferente. Não os ouça, eles estão errados.
2. Sim. Por exemplo, se um veículo for identificado exclusivamente como (lotid, VIN), o lotid é uma chave estrangeira para a tabela de lote. Se você deseja encontrar todas as imagens para muito, poderá participar da tabela de veículos_pictures diretamente para a tabela de lote, usando um subconjunto da chave do veículo_pictures (lotid em (lotid, vin)). Ou, não estou entendendo você?
3. Esquema, a interface vem em segundo lugar. Se o esquema é ruim, ter uma boa interface não é uma meta de longo prazo.