Executando verificação de segurança...
4

Você deu bem mais detalhes, mas não todos que são necessários, e eu já dei a base e respondi em: https://www.tabnews.com.br/jonwlf/nosql-ou-postgresql-tenho-duvidas-sobre-o-que-e-melhor-para-o-meu-cenario.

O grosso de quase todos os sistemas são de dados estruturados, mais ainda, costumam ser tabulares, não tem porque usar outra coisa já que os relacionais conseguem lidar com dados não estruturados também. A pá de cal no assunto é o fato de ter muitas informações relacionadas, um modelo de documento é péssimo nisso e não ten solução boa, é bastante recomendado não fazer, apesar de possível.

Um erro que muitos cometem é seguir modinhas e ir para um modelo de documento sendo que ele não precisa nada disso ou em pequenos detalhes do sistema. Quase sempre pagam um preço pela flexibilidade que é pouco ou nada usada e não tem soluções tão boas quando se quer mais robustez.

Se não tiver um motivo forte para usar NoSQL, não use.

Porém, faltando informações, e aí é para ficar no relacional mais ainda, não sabemos toda a complexidade que isso poderá ter um dia. Ao mesmo tempo tenho que dizer que se for só isso mesmo, só com as informações que eu tenho, eu digo que tanto faz, parece um sistema simples demais para se preocupar com a ferramenta certa. Mas posso estar falando porque não sei tudo o que eu deveria saber, o que indica que o problema é mais embaixo.

Sim, este parece ser um sistema muito simples, as pessoas perderam a noção do que é complexo.

Claro que se você precisa de algum dado não estruturado, em formato de documento mesmo, que é diferente de armazenar um documento, seria bom ter um relacional mais poderoso, embora você consiga fazer até com o SQLite, é mais fácil no Oracle, SQL Server ou PostgreSQL. Parece que o MySQL estava melhorando bem nisso também.

Se você usa um tipo de dados não estruturado como JSON ou faz a normalização adequada no relacional você não tem dificuldades, se souber o que está fazendo. Se você precisa estruturar e relacionar uma parte dos dados um MongoDB. por exemplo, funcionará mas precisa muito saber o que está fazendo e não dará o resultado que teria em um relacional.

Sempre adote a mais simples solução que tiver disponível.

De qualquer forma, escolher a tecnologia que vai usar é fácil, saber usá-la da maneira correta é muito mais difícil, por isso eu sempre falo que a pessoa precisa de formação completa, não pode só decorar receitas de bolo, cada problema é diferente, receitas de bolo não funcionam a não ser para problemas muito simples.

S2


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

Carregando publicação patrocinada...
2

Abrindo um parênteses.

Eu acho que o "noSQL" é mais uma redescoberta do que uma modinha. Se for falar apenas em Redis, MongoDB, etc., até é aceitável a "modinha". Mas hoje em dia ainda existem sistemas de grande a enormes que usam noSQL.

Começou com MUMPS/M (a IBM também tinha um projeto) na década de 60. Mas o que não começou na década de 60 em TI?

Área médica:
Em 1978 foi lançado o VistA e roda redondo até hoje. Existem outros usuários grandes como Partners HealthCare, Meditech, GE Healthcare, EPIC, EMIS entre outros.

Área financeira:
Ameritrade com 12 bilhões de transações por dia, Banco da Inglaterra, Banco Barclays entre outros.

Diversas áreas como: mapear a via láctea, universidades/bibliotecas, etc..

O único problema que eu vejo: É muito mais fácil conseguir alguém que "entenda" de SQL do que alguém que entenda de noSQL(M).

Diferença de relacional e não relacional. Fonte: https://www.cs.uni.edu/~okane/

Teste de velocidade MUMPS/M (YottaDB) e Redis (teste local)

1

Eu sempre falei nisso. Eu nem gosto do termo NoSQL porque ele não quer dizer nada, hoje em dia é nada, porque esses DBs sequer ignoram SQL, pelo menos alguns, apesar de adotar outro modelo de armazenamento.