Que banco de dados devo usar, para um grande volume de dados?

A resposta seria Oracle. Mas dificilmente uma grande empresa faz contrato pra usar ERP de um desenvolvedor individual ou pequeno empresário. Maioria das grandes empresas usam SAP e similares. Considerando sua realidade, pode usar PostgreSql.

Ok.

O Oracle é gratuito?

A versão gratuita é limitada https://www.oracle.com/br/database/technologies/appdev/xe/faq.html

Oracle é caro, só para grandes empresas.

Ah, ok!

Realmente. Acabo de olhar: 12 GB de limite.

Enquanto o PostgreSQL é ilimitado.

É ele, mesmo!

Obrigado a vocês, mais uma vez, @j-menezes e @javaflex !

Quase sempre quando fala em banco de dados recomenda o uso do relacional, talvez por já ser mais que testado a sua eficácia no uso diario, no entanto me encanta o NoSQL em especial
o de Grafo.

Esse de fato acho muito interessante e está muito alem do modelo relacional.

Essa é uma boa discussão, @j-menezes.

Não conhecia o conceito de NoSQL e de banco de dados gráfico (como o Neo4j) e achei interessantíssimo. Creio que JÁ SEJA a tecnologia a ser usada, já que, de acordo com eles, as pesquisas são muito mais rápidas que o SQL (que já é rápido).

Sabe dizer se o Neo4j é gratuito? Não consegui entender isso, no site.

Até onde Eu sei é pago, tinham uma versão free limitada, mas precisa ver com eles como está a politica agora.

Oracle, SqlServer, PostgreSQL, MySQL

Não use NoSql ele não é para o que precisa.

Olha, o NoSQL não seria ruim neste caso não. É prático e tranquilo de implementar

Quase todo mundo acha isso, que NoSQL não se encaixa. Mas o modelo NoSQL de Grafo, é como o mundo real e ele não é relacional.

Também não recomendo NoSql neste caso. SGDB relacional é muito mais consolidado para soluções transacionais.

Quase todo mundo é muita gente.

No caso dele não se emprega, no caso dele deve ser estruturado, organizado etc.

Pessoal os bancos relacionais são empregados até hoje para soluções de grande porte.

Se emprega sim.
Neo4J NoSQL tambem e’ transacional e não tem nada que impeça de criar modelos pre’ definidos para os Nós tão pouco de pre’ definir as relações.

É a sua opinião.

Eu discordo

Pode discordar a vontade, fato é que funciona e é aplicável.
Logico que é a minha opinião. Mas tenho como provar.

Opa!

A discussão tá boa! kkk

Pelo que li a respeito do NoSQL, percebi que ele se aplica a qualquer tipo de projeto: do minúsculo ao exorbitantemente grande.

Percebi que ele se aplica ao meu NANOprojeto, também.

Porém acho que O QUE VOCÊS QUEREM DIZER com a discussão, acima, é: alguns de vocês PREFERIRIAM não usar o NoSQL em um projeto pequeno, já que o SQL resolve, perfeitamente, há décadas.

Realmente, vou preferir o SQL, pois já mexi (pouco, mas suficiente) com ele, no meu passado de programador amador. Se eu fosse mexer com NoSQL, teria que estudar mais do que meu tempo permite, para colocá-lo em prática.

Porém, apesar de não ser tão experiente quanto vocês, percebi que o NoSQL é aplicável a qualquer projeto, sim. Não há lógica em dizer que um banco de dados é aplicável-em-um-projeto-grande e não-aplicável-em-um-projeto-pequeno. Se ele serve para grandes projetos, imagine, então, em projetos minúsculos.

Em projetos pequenos, usar o NoSQL seria como matar mosca com tiro de canhão. Mas que mata, mata.

Faz todo sentido.

Eu ia colaborar antes nesse post sobre esse exato sentimento que você expressou também na pergunta inicial.

Isso é um erro comum na nossa área: achar que se uma tecnologia é adequada para projetos grandes então também servirá pra projetos pequenos.

Toda tecnologia que você escolhe tem prós e contras. E um projeto grande tem necessidades diferentes de um projeto pequeno. Então você tem que sempre analisar se para um projeto específico a tecnologia faz sentido ou não.

Exato.Porque não devemos ter uma “linguagem favorita” ou " tecnologia favorita".Temos procurar a tecnologia que nos melhor nos atenda e isso basta.No caso dele foi o SQL porque ela é que melhor atende ele neste momento,poderá que no futuro precise migrar para o NoSql,mas isso é somente um possibilidade.

Porque para sermos boms programadores devemos sair desse pressuposto que devemos saber de uma linguagem,mas sim um pouco de tudo

Eu também tenho provas suficientes para não utilizar esse banco para esse fim da pergunta, mas, cara eu sempre discordo mediante experiências e fatos reais, não vivo de modinha, vivo da realidade, tudo que é novo tem que se tomar muito cuidado antes de implementar, vale lembrar que o banco NoSQL tem suas restrições e o banco relacional é muito mais maduro e sua organização corresponde a duvida acima.

Não falo somente pela opinião eu falo realmente em princípios tidos em experiências.

Somente a equipe do Neo4J melhora ele a quase 20 anos.
São inumeros exemplos que eles postam de como portar o banco relacional para Grafo.
E você ainda vem dizer que tem experiencia no assunto.

Estou afirmando: não use banco NoSQL para organizar dados que porventura serão relacionados, isso é feito pelo banco relacional e também pelo fato precitado ERP, analisa o mercado e verifique se tem ERP com esse tipo de banco, talvez ache, mas, compare com um banco relacional.

Quer fazer relação, otimização, buscas avanças, filtros e que isso seja utilizado DESKTOP, WEB e MOBILE.

Não é uma discussão é um fato.

Tenho experiencia suficientes pára não utiliza esse futuro banco para os bancos atuais.

E uma empresa não condiz com a realidade, a totalidade e sim a exclusão a exceção.

Quer utilizar OK!

Eu estou falando minha experiencia e fatos

Obrigado.

Em relaçao a consultas SQL ele tem o Cypher que é mais eficiente que SQL menos custoso que as JOINS do modelo relacional

Você só está pontuando assunto, isso não é a realidade de ERP.

Tô rebatendo suas teses.
Veja bem, não é porque o Windows domina desktop que ele seja de fato a melhor opção.
SQL domina ERP mas e daí !!
Uma coisa não anula a outra.

Não é tese, é afirmação que já foi explicado mediante experiencias e fatos.

Não vou discutir mais, já deixei minha mensagem para o usuário da pergunta.

Efim, obrigado, não vou perder mais meu tempo.

Idem