Devemos usar restrições de chave estrangeira quando persistindo modelos de domínio?

Question

Um tempo atrás eu tive uma discussão com meus colegas sobre a persistência da Domínio e se devemos impor restrições de chave estrangeira no nível de banco de dados.

A minha primeira reacção foi a de que o próprio uso de um banco de dados relacional implicou a execução de tais restrições, mas alguns argumentaram que o banco de dados deve ser visto como nada além de um mecanismo de persistência e, portanto, devemos evitar qualquer lógica de negócios nele. Acabamos por não usar as restrições de chave estrangeira.

Aqui está a minha pergunta (eu espero que não seja demasiado genérico):? É considerada uma boa prática para impor restrições de chave nestes casos

Answer 1

Impor restrições, mas não contar com eles em sua lógica de negócios

• Não negócios lógica no banco de dados: Concordo com o princípio. E se o seu SQL não código de negócios confia nas restrições de banco de dados para verificar a sua consistência de banco de dados, então você deve repensar a sua lógica de negócios.
• Não há nada errado em ter restrições de banco de dados além a sua lógica de negócio. Especialmente porque coisas como a integridade referencial com ESTRANGEIROS chaves e outras restrições UNIQUE são fáceis de fazer e RDBMS estão fazendo esse trabalho para você de forma muito eficiente, sem muita manutenção.
• Será que você não use índices no banco de dados também, porque não é puramente persistência relacionados?
• encontrar e corrigir bug de software pode demorar algum tempo, mas você definitivamente não quer gastar ainda mais tempo limpando ou (pior) a perder alguns dados, só porque você salvou-se um problema de escrever script de linha de um para um FK. Realmente: o seu obter algo de graça aqui e seu rejeitá-la
• [EDIT-1]: você pode garantir que os dados em seu banco de dados seria gerido SOMENTE por meio de sua aplicação? Há sempre parecem ser exceções, a maioria por usuários avançados, que fazem às vezes (muito raramente :-) erros tomar e executar algumas instruções SQL para clean-up seu código, status de atualização (para valores inválidos por causa de erros de digitação) etc.
• [EDIT-2]: Construção Domain Driven modelo não é uma desculpa para não contratar um administrador bom DB. Usando ORM não é uma desculpa para não contratar bom desenvolvedor DB.

Mas se você e sua equipe são capazes de escrever software livre de bugs e lidar com todos os cenários possível exceção em seu código (incluindo falhas de hardware / rede / usuário manequim / programador de erros), seguida "Hei, por que se preocupar com o redundante restrições FK ...." - -teaser -

Answer 2

Eu acho que sim, eu considerá-lo não tanto algo para lógica de negócios, mas impedindo dados "ruins" de serem inseridos no banco de dados. Uma vez que o banco de dados torna-se muito grande estes constrangimentos vai evitar dores de cabeça no futuro.

Isto especialmente entrará em vigor quando você tem vários desenvolvedores desenvolver aplicativos contra os mesmos dados. Isso irá garantir que eles também só pode inserir dados válido. Tendo restrições controlado em 1 spot em vez de x aplicativos é certamente benéfico.

Answer 3

Eu me sinto como ignorando ferramentas muito úteis (de integridade de dados em nível de banco de dados) por causa de uma metodologia de desenvolvimento puro é contraproducente. Bancos de dados são realmente bom neste tipo de coisa ... deixá-los fazer isso.

Em algum ponto cada metodologia começa a quebrar e você apenas tem que ser prático.

Answer 4

Eu costumava pensar assim, mas minha opinião mudou desde que eu comecei a escrever um monte de sistemas orientados a recursos. Normalmente, muito mais do que restrições de chave apenas estrangeiros são necessários para validar um pedaço de dados - por exemplo, um bilhete que está em estado de "atribuído" deve ter um válido "assigned_to" valor, e assim por diante. Todas essas regras devem ser colocados em uma rotina de validação de algum tipo, e embora teoricamente não pôde mágoa ter validação adicional no nível de banco de dados, se a sua validação em nível de aplicativo está trabalhando, verificando o estrangeiro restrição de chave é apenas desperdício de ciclos. Muito pior, no entanto, agora você tem lógica sobre o seu modelo de dados repetida em dois lugares - o código de validação e as restrições de banco de dados.

Pense nisso desta maneira: se você deseja mover qualquer outra lógica de aplicativo no banco de dados (por exemplo, através de procedimentos armazenados) se você não tem que? Se você não foram forçados a fazê-lo por considerações de desempenho, eu acho que a resposta deve ser geralmente "não".

Answer 5

"A minha primeira reacção foi a de que o próprio uso de um banco de dados relacional implicou a execução de tais restrições, mas alguns argumentaram que o banco de dados deve ser visto como nada além de um mecanismo de persistência e, portanto, devemos evitar qualquer lógica de negócios nele. acabamos por não usar restrições de chave externa ".

Sim, bem, a maioria medíocre sempre ganha esse tipo de debate por mera força dos números, infelizmente.

Se você ainda quer lutar essa batalha, você pode pedir a seus oponentes como eles pretendem impedir ninguém de usar "editores de banco de dados direta" (ala db2-aid, SPUFI, ...) e como eles pretendem impedir ninguém de corrompendo o banco de dados usando essas ferramentas (que ignoram suas restrições de negócios programados por definição).

Answer 6

Se você quiser seguir o projeto paradigma Domain Driven, então a resposta seria sim para qualquer coisa dentro de um agregado, e não por quaisquer ligações entre agregados.

Em quase todos os casos, você quer qualquer coisa sob o Aggregate Raiz a ser eliminado quando a própria raiz é excluído, e assim ter chaves estrangeiras que representam este, com eliminações em cascata, permitir-lhe atingir isso no nível de banco de dados. Você também pode ter seus repositórios fazer a cascata exclui-se se você não quiser fazê-lo em um nível DB, mas o ponto ainda está de pé que as crianças agregadas não devem existir sem a raiz.

Para preocupações cross-agregadas, você provavelmente vai ser lidar com decisões de negócios, como o que deve acontecer quando um ou o outro é removido. Muitas vezes você vai querer lidar com isso de forma assíncrona para permitir a escalabilidade, e assim suas extremidades modelo de domínio por ser, eventualmente consistente. Portanto, não faz sentido nestes casos para reforçar as chaves estrangeiras como haverá uma janela de tempo em que uma ou a outra chave pode não existir.

Espero que ajude! E para mais informações, definitivamente verificar para fora livro de Evans em Domain Driven Design -. e as muitas ligações em toda a web também