TL; DR: Restrições de relacionamento devem estar no banco de dados.
Sua inscrição não é grande o suficiente.
Você está correto, de fato, que impor relacionamentos entre os bancos de dados pode exigir sua aplicação no aplicativo.
Gostaria de salientar, no entanto, que você deve primeiro verificar a documentação do software de banco de dados que está usando e verificar as ofertas de produtos existentes. Por exemplo, existem ofertas de clustering no topo do Postgres e MySQL.
E mesmo se você precisar ter alguma alguma validação no aplicativo, não jogue fora o bebê com a água do banho . Afinal, quanto menos você tem que fazer, melhor para você.
Por fim, se você estiver preocupado com problemas futuros de escalabilidade, receio que seu aplicativo tenha que passar por mudanças significativas antes que possa ser dimensionado de qualquer maneira. Como regra geral, cada vez que você cresce 10x, você tem que redesenhar ... então não vamos gastar muito dinheiro em deixar de antecipar os problemas de escalabilidade, e em vez disso usar o dinheiro para realmente chegar ao ponto em que você tem esses problemas.
Sua inscrição não está correta o suficiente.
Qual é a chance de que o banco de dados que você usa tenha uma implementação defeituosa da verificação em comparação à chance de que sua aplicação tenha uma implementação defeituosa da verificação?
E qual você altera com mais frequência?
Eu apostaria que o banco de dados está correto, a qualquer momento .
Seus desenvolvedores não estão achando distribuídos o suficiente.
Reduce network round trip to application when insert/update data as application has to make more query(s) to check data integrity.
Bandeira Vermelha ! 1
Se você está pensando:
- verifique se o registro existe
- se não, insira o registro
então você falhou o problema de simultaneidade mais básico: outro processo / thread pode estar adicionando o registro durante o processo.
Se você está pensando:
- verifique se o registro existe
- se não, insira o registro
- verifique se o registro foi inserido como duplicado
você falhou para contabilizar o MVCC: a exibição do banco de dados que você tem é um instantâneo no momento em que sua transação foi iniciada; ele não mostra todas as atualizações que estão ocorrendo, e talvez nem esteja comprometido.
Manter restrições em várias sessões é um problema realmente difícil, fique feliz que tenha sido resolvido em seu banco de dados.
1 A menos que seu banco de dados implemente corretamente a propriedade Serializable; mas poucos realmente fazem.
Última:
And I think, handle data integrity in application will let to more verbose error message than using database. Eg: when you create an API server. If you define relations in database, and something go wrong(like the referenced entity doesn't exist), you will get an SQL Exception with message.
Não analise mensagens de erro , se você usar qualquer banco de dados de nível de produção, ele deve retornar erros estruturados. Você terá algum código de erro, pelo menos, para indicar o que está possivelmente errado e, com base nesse código, você pode criar uma mensagem de erro adequada.
Note que na maioria das vezes o código é suficiente: se você tem um código de erro dizendo que uma chave estrangeira referenciada não existe, então é provável que esta tabela tenha apenas uma chave estrangeira, então você sabe no código o que o problema é.
Além disso, e vamos ser honestos aqui, na maioria das vezes você não vai lidar com erros que graciosamente de qualquer maneira. Só porque há muitos deles e você não conseguirá explicar todos eles ...
... que apenas se conecta ao ponto correção acima. Cada vez que você vê um "500: Internal Server Error" porque uma restrição de banco de dados disparou e não foi manipulada, isso significa que o banco de dados salvou você, já que você esqueceu de manipulá-lo no código.