Modelo de Dados
O banco de dados do projeto está classificado como “item a ser definido” no documento de escopo. Esta seção será atualizada conforme a definição da tecnologia e modelagem.
Considerações Arquiteturais
A escolha do banco de dados é uma decisão crítica para o Promete, especialmente considerando a natureza do módulo de Relacionamento, que propõe um grafo de vínculos entre pessoas, organizações e territórios.
Desafios de Modelagem
| Desafio | Descrição |
|---|
| Grafo de relacionamentos | Consultas que envolvem múltiplos níveis de vínculo (ex: “pessoas ligadas a organizações de um território que têm demandas sobre saúde”) exigem modelagem otimizada |
| Volume de dados | O sistema deve suportar dezenas de milhares de contatos com histórico completo de interações |
| Performance | Consultas complexas no grafo não podem comprometer o tempo de resposta da aplicação |
| Flexibilidade | Novos tipos de relacionamento e atributos devem poder ser adicionados sem reestruturação do banco |
Abordagens Possíveis
| Abordagem | Tecnologia | Prós | Contras |
|---|
| Relacional com otimização | PostgreSQL (via Supabase) | Maturidade, ecossistema, equipe familiarizada | Consultas de grafo complexas podem ser lentas |
| Banco de grafos dedicado | Neo4j, ArangoDB | Performance nativa para consultas de grafo | Complexidade adicional na stack, curva de aprendizado |
| Híbrido | PostgreSQL + extensão de grafos | Equilíbrio entre familiaridade e performance | Complexidade de manutenção |
Recomenda-se que a definição do banco de dados considere benchmarks com o volume esperado de dados e os padrões de consulta mais frequentes do módulo de Relacionamento.
