VaccineCard/backend

Avaliando a possibilidade de usar Duplas Base de dados

Closed this issue · 9 comments

A medida que a aplicação vai crescendo, começo a perceber certos problemas que irão influenciar a veracidade as queries.
Então acredito que para resolver esse problema, séria melhor repensar o plano de funcionamento do BD ( Postgres )

Um usuário no vaccine card desponibliza muitas informações ( As dele, as de familiares ligados, As de filhos adicionados, As de doutores aceites ) Isso complica muito no relacionamento usando o modelo relacional ... Para corrigir esse problema sugiro a retira de toda a informação concernente ao usuário do banco de dados relacional para um não relacional ( NOSQL ) Podemos usar o mLab, sendo que a app ainda está em desenvolvimento

Assim para além de manter a performance, garantiria a veracidade das queries

  • O que idealizei séria que tudo relacionado ao usuario ficaria em um banco de dados não relacional
  • Usar duplos bancos de dados ( mLab e Postgres )

@JoseCage peço sua participação

É um ponto interessante @acidiney
Mas até certo ponto, acredito não haver necessidade de implementar algo de grande escala "multiple DB".

A app pode crescer sim, mas ainda assim estamos a falar de milhões de dados para exigir usar essa opção. O que sabemos que no nosso mercado não é de 1 para 2 anos que se consegue. Então ainda é cedo para pensarmos nisso.

A medida que a aplicação vai crescendo, começo a perceber certos problemas que irão influenciar a veracidade as queries.

E creio que com PostgreSQL por si só já lidamos minimamente bem com a questão de perfomance comparado ao MySQL

O ponto que eu estou presando muito é mais em relação a veracidade das queries

Ex:

Estou adicionando uma nova tabela Children

Possui
O id, nome , avatar, idPai,idMae, foto_do_cartao_de_vacina

O problema nisso é que pode existir situação em que ou o pai ou a mãe pode não ter conta no App e agora? Como se faria para registrar esses dados? E depois. Com essa table existiriam family_link que faz a ligação entre os usuários e o Children que faz a ligação de pais a filhos ... Nas queres tenho que fazer um belongsTo para recuperar dados pessoas dos links entre os usuários

'-' consegues entender o porque que estou sugerindo mover isso tudo para um único documento o quanto antes? E sem dizer que quanto mais rápido resolver esse problema menor será os problemas de manutenção num futuro

consegues entender o porque que estou sugerindo mover isso tudo para um único documento o quanto antes?

Literalmente não. Não entendo o porquê de querer mover. Não sei a tua disponibilidade (que aparenta ser 99%) mas de lembrar que o projeto a principio teve como objetivo ser um projeto de competição para o Hackathon CDA. Que ainda não se em que pé está.

E eu em particular não pretendo me empenhar em algo que ainda não sei como está e como estará daqui a tempos.

Tenho alguns projetos prioritários ao Hackathon.

@acidiney Discordo da ideia de adicionar mais uma BD 👎 recomendaria usar Replicação de Dados ou Escalabilidade, quanto a performance das queries hum bom assunto 🤓 o Postgres em termos de Performance é um excelente SGBD, concerteza que aí depende de como vai implementar essas queries poderia usar Particionamento ou Cache na BD

Dá uma lida em detectando problemas de performance no Postgres

@nelsonmfinda, então a ideia de usar outra BD não relacional, é para evitar problemas no futuro. Claro, agora não é muito importante mas com certeza num futuro, isso vai ser bastante incomodo.
E sim, nós já usamos o Postgres por causa da performance.
Vou dar uma checagem no link que você deixou ^-^