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

Pelo que entendi há muito tempo, de forma exclusiva arc uma tabela contém várias colunas que são chaves estrangeiras para outras tabelas, mas apenas uma delas pode ser definida por vez (devido a alguma restrição lógica no domínio decorrente 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 tem um valor.

Vou dar um exemplo. Considere um aplicativo em que uma empresa mantém o controle de os caminhões que usa para entregar as mercadorias. Um caminhão só pode estar em um dos três lugares ao mesmo tempo: pode estar com um funcionário, pode estar em um estacionamento ou pode estar em uma oficina de manutenção. Isso pode ser modelado por ter 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 é preenchido no nível do banco de dados. Código incorreto ou alguém com acesso direto ao banco de dados poderia inserir um registro com dois ou três campos preenchidos, o que equivale a corrupção de dados no banco de dados.

Comentários

• Os três locais de caminhão possíveis são subclasses de uma superclasse, " localização do caminhão ". Existem muitos casos em que as subclasses são mutuamente exclusivas. O desafio é como modelar classes e subclasses em tabelas relacionais.
• Concordo que há casos em que o uso desse design é justificado. Posso, no entanto, também concordar com a postagem original de que esse padrão é usado MUITO mais do que deveria. Também tem algumas desvantagens muito grandes …
• Não pode ser usada uma restrição de verificação? 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)). Eu não ' não gosto de arcos exclusivos, mas eles podem ser aplicados com uma restrição de verificação. É claro que a restrição FK também deve estar presente.
• Portanto, as " restrições de verificação complexas, apesar de " da postagem citado acima. Você pode ser capaz de fazer uma validação realmente sofisticada com restrições de verificação ou, diabos, até mesmo gatilhos, que não ' não a tornam uma boa ideia ou um símbolo de bom design. Imagine fazer a verificação de restrições em arcos exclusivos com quatro ou cinco colunas … Além disso, eu ' tenho quase certeza de que nem todos os mecanismos de banco de dados suporte a restrição CHECK . O MySQL declara explicitamente nos documentos que as cláusulas CHECK são analisadas, mas ignoradas …
• Esta fonte recomenda o arco exclusivo. Pensamentos?

Não há nada de mal em arcos exclusivos. Basta aplicar a regra de negócios correspondente usando uma restrição de verificação. A maioria dos principais sistemas de gerenciamento de banco de dados oferece suporte a 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.