Estou relativamente recém-saído da faculdade, por isso a maior parte da minha familiaridade com bancos de dados relacionais é do meu curso de bancos de dados, onde qualquer coisa que não esteja no BCNF ou no 3NF é uma farsa. Certamente esse é um extremo, mas minha equipe no trabalho realmente leva isso ao extremo oposto.
Em nossos esquemas de microservice db, as entidades raramente têm mais de uma única tabela. Tudo o que você normalmente normalizaria em outra tabela é armazenado em uma coluna json. Se for descoberto posteriormente que uma das propriedades desse json precisa ser consultada, uma nova coluna será adicionada e os dados serão armazenados nos dois locais (sim, em duas colunas diferentes na mesma tabela).
Em muitos casos, essas colunas json definitivamente têm uma vantagem. Se você nunca precisar consultar esses dados e nunca precisar fazer uma alteração unilateral nesses dados (o que obviamente não pode prever), não é uma má idéia. Além disso, muitos de nossos serviços não veem servidor ou estão hospedados em máquinas com uma quantidade obscena de espaço em disco para o que precisavam, portanto a duplicação de dados não é um grande problema. (Embora algo que eu geralmente gostaria de evitar fora da filosofia)
Atualmente, estamos construindo um serviço que corresponde às regras com base em um conjunto de condições que elas possuem e, em seguida, executa um conjunto de ações associadas a essas regras quando as regras são verdadeiras (por exemplo, todas as condições são verdadeiras). Minha sub equipe que mais imediatamente construiu esse serviço acredita que há um benefício substancial em normalizar ações e condições fora das regras do esquema. Obviamente, essas tabelas mantêm relacionamentos de chave estrangeira com o ID da regra. Da nossa perspectiva, podemos evitar a duplicação de dados em condições, o que nos permite garantir que eles sejam avaliados apenas uma vez e é fácil encontrar as condições e regras necessárias quando precisar delas, sem precisar extrair todas as regras e fazer a pesquisa na memória.
Hoje, conversando com um de nossos principais engenheiros, ele tentou me afastar desse esquema. Tentar argumentar de todas as maneiras que nós realmente não precisamos, isso causará problemas de desempenho no futuro, referenciando um antigo monólito que possuímos que é um travesti de design. Ele se referiu ao que estamos fazendo como "o caminho antigo" e as tabelas planas com json como "o novo caminho". Ele argumentou que em lugares onde eu quero atomicidade, não precisamos dela e que, em vez de consultas, devemos fazer mais coisas na memória. Esse é um princípio de design que muitos de nossos serviços seguem agora. Não prevemos que o volume de nossos dados aumente substancialmente, o que deve manter nossas consultas rápidas. O que antecipamos é muito tempo gasto na avaliação de regras e na execução de ações.
Entendo que bancos de dados não relacionais se tornaram mais populares nos últimos anos, mas mesmo ao pesquisar ativamente informações sobre as implicações de desempenho dos relacionamentos com chaves estrangeiras, não vejo muita informação justificando seu argumento. Suponho que eles tendem a introduzir grandes transações que podem causar problemas, mas isso parece ser um problema independente da própria chave estrangeira.
Esta é a minha ingenuidade? Ou existe realmente algo que eu e minha sub-equipe estamos perdendo? Eu explicitamente não forneci informações detalhadas sobre o nosso problema, porque não estou necessariamente procurando uma solução para isso. Dado que é uma tendência comum em nossa equipe maior, estou realmente curioso para saber se eles estão envolvidos com isso.