Tô fazendo um projeto pessoal de um mini erp usando react, e node no back, é projeto pra mais de ano claro, sem pressa de terminar, porém tava pensando qual a melhor database pra fazer o sistema de estoque, qual a opinião de vocês? por enquanto já tenho o sistema de login e registro pronto e funcional e um protótipo de dashboard
Não é bem assim que você deve fazer a análise. A forma como você vai fazer pode definir mais o que é útil. E aspectos políticos provavelmente pesarão mais que os técnicos.
Só não pense em usar MongoDB. Até dá, mas ficará péssimo. um ERP praticamente exige um banco de dados relacional, nem passe perto de outros. quem usa um modelo de documento em caso assim vai abusar muito dele. Precisa muita ingenuidade para usar NoSQL em algo que claramente será todo de dados tabulares, com relacionamentos e com schema essencialmente fixo (a maioria dos bancos relacionais hoje permitem flexibilidade quando precisa).
Lembrando que hoje quase todos os relacionais possuem pelo menos 2, 3 ou mais modelos operando junto além do relacionam, entre documento, grafo, espacial, chave e valor, RDF, time series, vetor e até colunar, e todos permitem uma forma básica ou sofisticada de busca textual que pode servir para a maioria dos propósitos.
Você pode usar até o SQLite e provavelmente vai bem. Eu sei que muita gente acha que não, mas já usei, conheço várias pessoas que usaram e quem entende de banco de dados com profundidade sabe que dá. Desde que o volume de escrita concorrente nele não seja muito grande e tome alguns cuidados, pode ser até que precise criar uma fila. Ou seja, não é para qualquer um adotar isso. Você ficará mais tranquilo com o outro produto.
Quer algum produto de baixa popularidade? Geralmente a maioria não quer, então elimina dezenas ou centenas deles, por exemplo DB2, Informix e talvez até o Firebird que é o mais usado entre os pouco usados e o menos usado entre os mais usados. Nenhum deles é ruim, o problema é a baixa popularidade.
Depois precisamos ver sobre você aceitar pagar pelo produto ou não. Embora muitos produtos possuem uma versão com limitações (em geral cada base de dados pode ter só 10GB de tamanho e costuma não ter certas otimizações), se quiser ter liberdade para além disso sem pagar não pode escolher Oracle ou SQL Server. Provavelmente os dois SGDBs mais poderosos do mercado, com folga, sendo o primeiro o maior de todos. Obviamente também são os mais difíceis para obter o melhor resultado que só eles conseguem entregar. Se vai pagar e consegue se virar para arrancar o melhor deles, pode escolher um dos dois, estará muito bem servido para qualquer carga de trabalho. Eu acho que não é o caso, mas está aí.
Pois bem, sobrou apenas PostgreSQL e MySQL. Na verdade, hoje quando alguém fala de MySQL no fundo está falando de MariaDB. Quase ninguém usa o MySQL por escolha realmente, geralmente usa por legado ou porque não sabe que o MariaDB existe, que é o mesmo produto em quase tudo, é praticamente um fork. Cada vez mais haverá diferença entre eles, mas até mesmo a licença e o fornecedor ajuda escolher o MariaDB.
Se for escolhê-lo então precisa ver se vai usar o InnoDB ou outro mecanismo de armazenamento. Sinceramente, se não for usar o Aria (ou MyISAM no MySQL), não sei se ele tem tanta vantagem assim. O InnoDB de fato tem várias vantagens, mas também tem desvantagens, e se ele for o indicado para você eu acho que o PostgreSQL é melhor. Porque o InnoDB perde algumas facilidades e performance que o Aria te dá, mas não dá tudo o que o PostgreSQL te dá.
Pra falar a verdade vai fazer pouca diferença. Eu até acho o PostgreSQL mais robusto para aplicações grandes, mas está provado que o MySQL dá conta muito bem, provavelmente só no InnoDB. O jeito que fará a aplicação definirá o que é melhor. Um ERP poderoso pode se dar melhor com PostgreSQL, mas um mais simples terá vantagens com Aria.
No fim, para um produto simples o que definirá mesmo é qual você está mais familiarizado. Se você souber o que está fazendo qualquer um dá conta e saber usar melhor é que dará o melhor resultado. Se não souber nenhum e puder aprender bem, pode seguir o que eu falei. Se não souber nenhum e acha que não poderá aprender qualquer um deles bem, então vai de MariaDB/MySQL, de preferência com Aria/MyISAM que é mais fácil. Mas o produto vai sofrer nessa condição. Certamente esses DBMS criados pelo Monty Widenius são mais fáceis de usar por iniciantes.
Cuidado com a ideia de usar algo para aceitar vários DBs diferentes. No fim fica ruim para todos, ainda mais se a pessoa não souber muito bem o que está fazendo, e se adotar isso provavelmente não sabe. Fica pior que um pato (veja mais, também).
Em resumo, exceto o SQlite, que tem características únicas que os outros não conseguem, todos os outros relaciconam darão conta do recado, desde que você saiba usar bem, ou mesmo sem saber, dsde que o volume não seja gigantesco (as pessoas tendem a achar que seu sistema será usado por ordens de magnitude maiores do que efetivamente será, por isso o SQLite provavelmente dará conta também, e o MongoDB não será trágico em performance, mas ainda será em consistência).
Reforço a ideia que a forma como fará é que deveria definir qual é o mais adequado para você. Se não sabe como vai fazer, até um sorteio poder funcionar. Engenharia é ter domínio de todo o processo.
Minhas respostas sobr DB no SOpt: https://pt.stackoverflow.com/search?tab=votes&q=user%3a101%20%5bbanco-de-dados%5d&searchOn=3.
Faz sentido para você?
Espero ter ajudado.
(podia ter colocado um título mais significativo, se for editar poderia dizer que quer recomendação de banco de dados para ERP)
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).
Olá maniero, qdo vc diz para ter cuidado com a ideia de algo que aceite vários DBs diferentes, me parece que é algo contrário ao que geralmente ouvimos sobre clean arch e hexagonal, onde a recomendação é justamente criar o core da aplicação sem dependência de ferramentas externas, como o próprio DB. Se é isso mesmo, quais seriam os principais pontos que vc vê para defender essa ideia?
Sim, é o contrário mesmo. A experiência que eu tenho em 40 anos com vários sistemas,. fazendo ou dando consultoria, que usaram e não usaram isso, que tiveram todo tido de manutenção, sendo que eu não tenho que vender livros, curso, palestras ou consultoria cara que precisa criar complexidade, realmente não deve fazer essas coisas e deve seguir o YAGNI e o KISS, pelo simples fato que em 99,9% (número chutado obviamente) isso não se paga.
Eu sou extremamente crítico da complexidade. Quem vai adotar complexidade é que precisa justificar porque está fazendo isso.
Se você fizer isso paga o preço, independente de precisar ou não. E quase nunca precisa. Se não fizer, pagará um preço um pouco maior, não muito, para mudar se precisar. Quase nunca precisa e não paga. Então é uma decisão muito mais sensata. Se custasse um valor muito inferior fazer isso e mudasse com frequência, aí eu pensaria diferente. Até deixar de mudar, mesmo quando precisa, pode ser melhor que pagar esse preço. Além do que, conforme links que eu já passei, quase sempre, mesmo fazendo isso, a pessoa paga um preço para mudar também, além do preço pago para evitar custo da mudança, mas que quase nunca dá certo. As pessoas não notam a besteira porque quase nunca precisam, ou não ficam para ver quando precisa. O que as pessoas falam não é o mesmo do que acontece. O melhor é desenhar corretamente para não precisar mudar. Ou pagar o preço se precisar mudar.
Dá uma lida em https://pt.stackoverflow.com/q/441073/101. E depois faça perguntas específicas que eu respondo.
Obrigado pelo comentário.
Postgresql é vida mano! kk
Uma rápida busca você já encontra algo relacionado:
Why I chose PostgreSQL for my ERP Startup Project (Por que escolhi o PostgreSQL para o meu Projeto de Startup de ERP)
Realmente Postgres é um poderoso Database e muitas vezes subestimado, você pode ficar em dúvida entre ele e o Mysql mas em minha opinião o Postgres se sai melhor.
Você pretende utilizar algum ORM? Caso sim eu recomendaria deixar o projeto "agnóstico de banco de dados" de modo que se quiser começar com um SQLite você pode e se você trocar para um postgreSQL ou SQL Server também e não vai precisar alterar nada a não ser a configuração do banco de dados.
Na empresa onde eu trabalho a gente utiliza SQL Server, mas como o amigo já comentou, Postgres é a melhor opção devido as features (constraints, concurrency, full acid, etc) e o fato de ser totalmente gratuito. Como o ERP é bem antigo, estamos estudando bastante como será realizada a migração, mas com certeza iremos migrar para Postgres num futuro próximo.
Sem dúvidas o PostgreSQL, robusto e de confiança, vai funcionar bem em projeto pequeno e se o projeto crescer aí é que você vai ver que fez uma boa escolha, hoje tenho tabela com 10mi de registros, funcionando perfeitamente a vários anos.
Na minha opinião a melhor escolha seria o PostgreSQL.
Pra esse tipo de projeto um banco relacional é o que deve ser utilizado e o PostgreSQL é um banco de dados bem robusto, bom pra você escalar sua aplicação e fácil de ser utilizado. Acredito que vai te atender perfeitamente.
posso ajudar contribuindo para o projeto em troca de conhcecimento?
Eu sugiro primeiro construir as partes princípais do sistema baseado em testes, e sem depedências de ferramentas externas, e aí depois você pensa nos conectores, como qual bando de dados você vai utilizar.
E se for Web, da uma investida no Docker