Bom dia,
Tenho um cliente fazendo pesquisa científica. O design atual do banco de dados (Azure postgres) é 3NF, mas muito poucas transações estão acontecendo. Existem vários "pipelines" que adicionam novos dados às tabelas e os cientistas podem fazer uma atualização em alguns dados ou "descartar" alguns dados como errôneos, mas no geral muito pouco está acontecendo em termos de transações.
No entanto, eles têm um aspecto de “relatório” no seu trabalho e é isso que os cientistas fazem a maior parte do dia. Observar os dados (coisas genéticas) e ver se essas mutações foram vistas antes ou quais são os marcadores de início e parada, etc.
Por exemplo, uma de suas páginas da web de "relatórios" ou análise de dados chama uma visualização. Essa visualização leva mais de 4 minutos para ser executada. Quando olho para essa visualização, basicamente estou reunindo todos os dados das diferentes tabelas 3NF e achatando-os em 1NF para depois exibi-los.
Então aqui estão meus pensamentos/perguntas:
As tabelas 3NF e 1NF poderiam existir no mesmo banco de dados e no mesmo esquema? Eu sei que você poderia literalmente fazer isso, mas isso seria sábio/problemático? É algum tipo de "antipadrão" misturar e combinar assim?
1a. Se você fizesse isso, modificaria os pipelines para colocar os novos dados recebidos diretamente nas tabelas 1NF ou ainda deixaria o pipeline ser inserido no 3NF e então teria um gatilho ou processo ETL, etc.
1b O pensamento aqui é que se uma tabela existisse em 1NF, poderíamos simplesmente fazer uma varredura a partir dessa tabela, em vez de todas as junções, cte, subconsultas, etc., que estão atualmente na visão de longa execução.
Devo migrar toda a operação para 1NF entendendo que as poucas transações existentes serão mais lentas, mas 90% de todo o resto (sp, vw, fx, etc) será menos complexo e mais rápido.
2a. Se eu migrasse tudo para 1NF, você ainda teria tabelas de "teste" nas quais o pipeline grava os novos dados recebidos e, em seguida, um processo ETL carregaria os novos dados nas tabelas 1NF?
No geral, estou querendo planejar soluções de longo prazo. Claro que posso reduzir essa visualização de 4 minutos no tempo, mas a longo prazo, no que devemos pensar, especialmente porque o volume de dados continua a crescer. (aumento de 20% só no ano passado).
TIA
O que você descreve é uma arquitetura básica de data warehouse, onde você tem dados de transação normalizados e, a partir desses dados, carrega tabelas que são modeladas para fácil consumo e rápido desempenho de consulta.
Nas arquiteturas Lakehouse, essa ideia é geralmente chamada de "Arquitetura Medalion": https://learn.microsoft.com/en-us/azure/databricks/lakehouse/medallion
Mas quer você use um Lakehouse ou um banco de dados, o design é o mesmo. A camada de consumo da solução geralmente é modelada para consumo usando Modelagem Dimensional , que geralmente é mais útil e eficiente do que produzir tabelas amplas desnormalizadas.
Sua pergunta é um exemplo clássico da pergunta genérica:
Quem sabe? Depende inteiramente do motivo pelo qual 'A' não funciona como você espera.
Se 'A' não funcionar por causa de um problema simples e solucionável, você provavelmente deveria apenas consertar esse problema;
Por outro lado, se 'A' não funcionar por causa de um problema fundamentalmente impossível de resolver, você poderia tentar 'B' - contanto que você entenda que 'B' pode ser pior, então você teria perdido seu tempo mudando para 'B', e talvez até precise perder mais tempo voltando para 'A'!
Portanto, antes de alterar qualquer coisa, você deve determinar inequivocamente por que suas consultas atuais estão lentas.
Minha aposta é um ou mais dos seguintes:
Seu banco de dados não está devidamente normalizado;
As tabelas não possuem chaves primárias adequadas e/ou não estão indexadas corretamente;
Suas consultas são escritas de forma ineficiente.
Digamos que você tenha consultas que são executadas de forma inesperadamente lenta:
Escolha a consulta mais simples e lenta. (Por exemplo, escolha uma consulta de 10 linhas que seja executada 50 vezes mais lentamente do que você acha que deveria, em preferência a uma consulta de 1.000 linhas que seja executada 5% mais lentamente do que você acha que deveria.)
Descubra por que essa consulta é executada lentamente. Pergunte a alguém mais experiente, se necessário. Não prossiga até saber por quê!
Então proceda de acordo.
HTH