O que é arco exclusivo no banco de dados e por que é mau?

Eu estava lendo os erros mais comuns de design de banco de dados cometidos pelas perguntas e respostas do desenvolvedor no stackoverflow. Na primeira resposta houve uma frase sobre o arco exclusivo:

Um arco exclusivo é um erro comum em que uma tabela é criada com duas ou mais chaves estrangeiras, em que uma e apenas uma delas pode ser não nula. Grande erro. Por um lado, fica muito mais difícil manter a integridade dos dados. Afinal, mesmo com integridade referencial, nada impede que duas ou mais dessas chaves estrangeiras sejam definidas (apesar de restrições de verificação complexas).

Eu realmente não entendo por que arco exclusivo é mau. Provavelmente não entendi o básico disso. Existe alguma boa explicação sobre arcos exclusivos?

database-design

— Ali Arda Orhan
fonte

Respostas:

Até onde eu entendi há muito tempo, em um arco exclusivo, uma tabela contém um número de colunas que são chaves estrangeiras para outras tabelas, mas apenas uma delas pode ser configurada por vez (devido a alguma restrição lógica no domínio seguindo do mundo real). Como essa regra não pode ser aplicada no banco de dados, um registro corrompido pode ser criado onde mais de uma dessas chaves estrangeiras tiver um valor.

Eu vou fazer um exemplo. Considere um aplicativo em que uma empresa controla os caminhões que usa para entregar mercadorias. Um caminhão só pode estar em um dos três locais ao mesmo tempo: pode estar com um funcionário, em uma garagem de estacionamento ou em uma oficina de manutenção. Isso pode ser modelado com uma tabela Truck com employeeId, parkingGarageId e maintenanceShopId, referenciando as tabelas Employee, ParkingGarage e MaintenanceShop. Não há como impor a regra de que apenas um desses campos seja preenchido no nível do banco de dados. Código incorreto ou alguém com acesso direto ao banco de dados pode inserir um registro que tenha dois ou três campos preenchidos, o que equivale a corrupção de dados no banco de dados.

— JDT
fonte

As três possíveis localizações de caminhões são subclasses de uma superclasse, "localização de caminhões". Existem muitos casos em que as subclasses são mutuamente exclusivas. O desafio se torna como modelar classes e subclasses em tabelas relacionais.

— precisa

Concordo que há casos em que o uso desse design é justificado. No entanto, também posso concordar com o post original de que esse padrão é muito usado mais do que deveria. Tem algumas desvantagens muito grandes também ...

— JDT

Uma restrição de verificação não pode ser usada? Por exemplo

alter table mytable add constraint myconstraint check ((col1 is not null and col2 is null and col3 is null) or (col1 is null and col2 is not null and col3 is null) or (col1 is null and col2 is null and col3 is not null))

. Não gosto de arcos exclusivos, mas eles podem ser aplicados com uma restrição de cheque. Obviamente, a restrição FK também deve estar presente.

— Tulains Córdova

Daí as "restrições de verificação complexas, não obstante" do post citado acima. Você pode conseguir uma validação realmente sofisticada com restrições de verificação ou heck, até gatilhos, que não a tornam uma boa idéia ou um sinal de bom design. Imagine fazer restrições de verificação em arcos exclusivos com quatro ou cinco colunas ... Além disso, tenho certeza de que nem todos os mecanismos de banco de dados suportam a restrição CHECK . MySQL afirma explicitamente na documentação que CONFIRA cláusulas são analisados, mas ignorou ...

— JDT

Esta fonte recomenda arco exclusivo. Pensamentos?

— Alex Moore-Niemi

Não há nada de mal nos arcos exclusivos. Simplesmente imponha a regra de negócios correspondente usando uma restrição de verificação. A maioria dos principais sistemas de gerenciamento de banco de dados suporta restrições de verificação (Oracle, SQL Server, PostgreSQL). Se você estiver usando uma ferramenta de modelagem de dados, há uma boa chance de que sua ferramenta gere automaticamente o código para implementar a restrição de verificação.

— Gary B
fonte

-1

O arco exclusivo é muito útil no design conceitual ou lógico. Isso não significa que você precise implementar dessa maneira. No exemplo anterior, o designer pode decidir implementar o design com três tabelas. Um para o local de estacionamento, um para o funcionário e outro para a oficina de manutenção.

— Trevor Cummings
fonte