Documentation Index
Fetch the complete documentation index at: https://docs.promete.com.br/llms.txt
Use this file to discover all available pages before exploring further.
Modelo de Dados
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.