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

NoSQL ou PostgreSQL? Tenho dúvidas sobre o que é melhor para o meu cenário.

Olá pessoal, todos bem?

Eu quero criar uma aplicação para um nicho específico, onde será possível alguma ter iteração social, compartilhamento, App/Web, etc. Nada muito grandioso.

Eu domino C# e um pouco de Angular (nada de Mobile até então) e gostaria de saber o que é mais vantagem: Utilizar um BD NoSQL ou banco relacional.

Na minha humilde visão, utilizar NoSQL iria acelerar o desenvolvimento, pois o tempo de trabalho no back-end seria menor, ou estou enganado?

Faço este post para receber opiniões (obrigado caso participe).

Carregando publicação patrocinada...
8

Tem bem poucas informações sobre seu cenário. Uma das coisas mais importante para desenvolver um software e IA nenhuma faz isso e não vai fazer tão cedo é colher requisitos adequados, e eles precisam ser extensos, amplos, e olhando para o futuro também, sem cair no YAGNI.

Nada muito grandioso podemos dizer que literalmente qualquer coisa serve. Muito provavelmente, mas não podemos ter certeza pela falta de requisitos, até o SQLite pode ser adequado, se a pessoa souber o que está fazendo.

Eu nunca vi essa aceleração de desenvolvimento com NoSQL, a não ser que seja a única coisa que a pessoa saiba fazer. Nunca vi nada em SQL que fosse mais difícil de fazer, pelo menos quando a pessoa sabe fazer. Você tem que gravar dados e recuperar dados, não existe milagre, não tem tecnologias que vão fazer isso com uma linha muito simples quando a questão for complexa. Você pode ter um ganho aqui, uma perda ali, mas no fim dá na mesma. E mesmo que tenha um ganho mínimo com um, provavelmente a manutenção depois será muito pior, esse é um tradeoff quase inexorável.

Se usar um ORM dá literalmente na mesma.

Eu vou de relacional até que se prove que ele não é adequado, ele é poderoso e flexível, quase a prova de futuro (ou seja, mesmo que surjam novos requisitos, provavelmente ele dará conta se a pessoa modelou certo, e ainda dá mesmo se fez errado.

No fim, o que conta é a pessoa saber o que está fazendo, entender como são os modelos de dados existentes, como cada ferramenta trabalha.

Como informação adicional, o PostgreSQL provavelmente é o relacional mais próximo de atingir os objetivos que o NoSQL atende (na verdade o modelo de documento, né? porque se for outra coisa, a comparação parece errada - NoSQL não é um modelo de banco de dados, é um nome guarda-chuva para vários modelos, então a comparação nem cabe). Qualquer modelo NoSQL é para nichos muito específicos, ou para algo que tanto faz o que vai usar que dá na mesma, portanto mesmo não sendo o mais adequado, um MongoDB poderia te atender bem também, não sei o futuro.

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).

1

Muito obrigado pela contribuição, ajudou muito! Levando em conta o que você e outros colegas responderam aqui, seguir com banco SQL é mais vantagem e mais robusto para o futuro.

Eu tenho muito conhecimento com SQL e pouco conhecimento com NoSQL, e eu tinha uma ideia errada de que utilizar NoSQL iria agilizar de alguma forma o desenvolvimento da aplicação.

Obrigado também aos colegas Oletros e joevtap que também responderam neste post.

5

NoSQL (usando o termo genérico) brilha em aplicações de big data (que normalmente os dados são não estruturados ou semi-estruturados) e cloud native (por causa do sharding, escalabilidade horizontal de bancos de dados distribuídos, como o Cassandra e o próprio Mongo).

SQL brilha em quase tudo e provavelmente é o suficiente pra qualquer aplicação que uma pessoa sozinha vai fazer.

Seu projeto parece ser orientado a relacionamentos, então um NoSQL que se encaixaria em parte da aplicação, por exemplo, sistema de recomendação, é um Neo4J ou outro orientado a grafos. Mas pra persistência dos dados mesmo, como banco principal, um SQL como PostgreSQL ou SQLite que seja é completamente ok.

Hoje também existem soluções SQL Cloud Native, como o Neon e o CockroachDB, então se a necessidade é escalabilidade horizontal ou serveless (que o Mongo tem pelo serviço do Atlas), isso você também encontra com um banco SQL.

Concordo com o @maniero e não acho que acelere o desenvolvimento usar um NoSQL em vez de um SQL. Usa um ORM como o Dapper ou o próprio Entity Core Framework e você estará bem servido.

2

Isso, esses DBs não relacionais não são para aplicações tradicionais que maioria das pessoas desenvolvem, o uso indiscriminado deles é por modinha, só uma pequena parcela é real necessidade.

Embora ele tenha uma possibilidade de ter um grafo no geral, duvido que seja necessário um DB assim, porque é um ponto específico e de forma muito simples, perfeita e facilmente resolvível com relacional. Mas só estou especulando, como todos aqui, não temos maiores informações.

O que o pessoal acha que demora mais com relacional tradicional é porque precisa planejar melhor oque vai fazer, enquanto que com MongoDB pode fazer uma zona mais facilmente, mas isso cobra um preço caro depois. É o que eu falei, relacional te quase te obriga saber o que está fazendo, documento não, mas também deixa a zona tomar conta, o que pode não ser problema na maioria das aplicações que são tão simples que não importa nada disso.

5

Meus 2 cents:

Como a pergunta foi bem generica e sem maiores informacoes, entao vai uma resposta bem generica:

  • Se a aplicacao eh WEB ou um APP online e os dados tem estrutura definida (entidades e campos pre-definidos como usuarios, posts, amigos, etc) entao um banco de dados relacional (p.ex. postgresql) parece fazer mais sentido.

  • Por outro lado, se a estrutura dos dados nao eh tao rigida ou vai mudar muito, a opcao NoSQL parece ser mais adequada.

De um modo geral: olhe para teus dados - se voce visualiza separacoes bem definidas em entidades com campos e relacionamentos, entao BD relacional provavelmente eh o caminho. Se os dados nao tem tanta estrutura e relacionamentos nao sao tao importantes ou definidos - o NoSQL pode ser mais interessante.

Quanto ao trabalho (maior ou menor): nao analisaria por ai - no final das contas nao faz tanta diferenca a medio/longo prazo (relacional da um pouco de trabalho extra no inicio, pois existe a necessidade de pensar em como serao montadas as entidades e relacionamentos, mas tem a vantagem de te forcar a planejar em como a aplicacao vai funcionar no final).

Mas veja, eh uma analise bem superficial - mas espero ter ajudado.

2

Se a estrutura não for rígida um DB relacional dá conta muito bem também, especialmente o postegrSQL. Essa justificava para adotar MongoDB já não é mais válida há bastante tempo. Claro que se for completamente sem estrutura ele pode ser melhor, ainda que relacionais atendem também, alguns de forma melhor que outros (na verdade é só questão de facilidade). Mas um DB completamente sem estrutura é muito raro, quase sempre se tem algo estruturado e uma pequena parte é mais flexível, ou seja, PostgreSQL ou outro relacional vai atender melhor em quase todos os cenários.

3

Meus 2 cents extendidos:

Sim, mesmo BD relacionais atendem dados de-estruturados (p.ex. postgresql tem campo json).

Meu olhar foi em pensar em um APP no sentido mais "muderno" (grafia propositada), algo que roda principalmente no mobile e pouco (ou quase nada) na web ou em dados remotos.

Neste tipo de APP (de um modo geral) o NoSQL faz mais sentido.

Para APP tradicionais (ainda que tenham versao mobile), o relacional de um modo geral faz mais sentido.

Mas sao analises que precisam ser feitas caso-a-caso: eh arriscado apontar o melhor caminho sem conhecer os detalhes de usabilidade ou mesmo estrutura de dados.

3

Se você tem dúvida você não está preparado para garantir a confiabilidade dos dados em um NoSQL, então vai de postgres

utilizar NoSQL iria acelerar o desenvolvimento

Sim, mas isso tem um custo. Geralmente o custo é aumentar muito a complexidade da aplicação. Você está preparados para isso?

2

Se voce tem dúvidas e nao conseguiu justificar o porque, vai de PostgreSQL. O resto é moda e aventura que irá lhe cobrar o preço mais a frente.
Para comparação, o Notion ainda usa PG.