Eu pensei muito na forma de responder esta pergunta.
O melhor SGDB para tabelas grandes e que trabalha bem com Scriptcase é: TODOS E NENHUM!
.TODOS os SGDB´s tem bases com 400GB ou mais rodando pelo mundo com performance.
Seja Firebird, a tripa sertaneja MySQL/MariaDB/Percona, Postgresql, Microsoft SQL Server, Oracle e etc.
Se não tivessem performance com bancos ou tabelas grandes estariam fora do mercado em instantes.
.E NENHUM deles está isento de bugs, má configuração, ausência de um DBA, hardware sofrível, sistema operacional mal configurado, bugs do scriptcase, select * from em tabelas grandes e etc.
Mas vou te dizer como achar o melhor SGDB para seu caso. E para isto vou de dar uma notícia boa e outra ruim.
Vamos a notícia boa primeiro.
Você faz parte dos 10% mais ricos.
Contrate um excelente DBA e um cara de TI que saiba os hacks do sistema operacional usado e que mantenha seu hardware voando.
Escolha uma linguagem de programação e faça suas POGS (traduzindo para os noobs -> programação orientada a gambiarras). Enfim seja feliz.
Os caras acima que se virem para fazer o sistema voar. E acredite eles farão! E de quebra irão dizer onde você está errando nas suas POGS.
Vamos a notícia ruim.
Você como eu faz parte dos 90% mais… pobressss!
-
Escolha um SGDB que você goste/use e pela primeira vez na vida leia o manual dele. E quando digo ler o manual quero dizer todo ele.
Acredite que fazer insert, update, delete, criar FK, UNIQUE, PK, campos e etc até meu filho de 9 anos fará se eu ensinar.
Mas saber os recursos que o SGDB oferece, em qual situação determinado tipo de campo deve ser usado. Quais as variáveis nos arquivos de configuração devem ser mexidas. Que tipo de engine devo usar. O segredos da entrelinha do manual e etc. Bem, são poucas as pessoas que tem este conhecimento.
Olhe que muitos nem sabem a diferença entre a dupla char/varchar e quando usar um ou outro conforme o SGDB.
Ou mesmo qual o melhor tipo de campo para valores monetários.
Que tipo de índice criar e onde usar.
Até mesmo otimizar ou normalizar o banco.
Tem curiosos que desconhecem o “explain” e para que serve.
Não ler o manual de uma ferramenta de trabalho e como jogar futebol com uma bola feita de meias velhas.
Você joga, se diverte, faz gol, corre o campo todo atrás da bola, ri com os amigos, volta satisfeito para casa no final da partida. Mas ainda assim jogou com uma bola feita de meias velhas.
-
Leia o manual da linguagem de programação que você vai usar. Sim! Leia todo também.
Vou dizer exemplos pequenos:
Você usa pascal é acha que a diferença entre read e readln é quem um lê o que foi digitado e vai para linha de baixo e o outro permanece na mesma linha.
Usa PHP e acha que os comparadores == e === são mesma coisa com os mesmos resultados.
Crê que echo e print no php fazem o mesmo e não tem diferença, mas como a maioria usa echo eu também uso.
Somente tenho a dizer vixe! Nem suas POGS irão de salvar!
O detalhe e que ninguém para nos exemplos pequenos não é? Todos gostamos de complicar.
É ai que começa os seus problemas. Usar o que todo mundo usa sem saber o porque é a receita do grande desastre.
Pode levar anos. Mas ele acontecerá.
-
Aprenda o máximo do sistema operacional que você usa para instalar o SGDB.
E não estou falando de abrir word, navegador ou fazer uma planilha, instalar o SGDB com next, next e next.
Estou falando que um dia sua tripa sertaneja MySQL,MariaDB,Percona vai precisar que você configure o SGDB para poder abrir mais arquivos que o padrão porque seu bancos e tabelas cresceram junto com sua clientela.
Tudo bem né? Ai você vai e coloca no my.cnf ou my.ini open_files_limit = 256000
Tá resolvido né?
Mas esquece, por exemplo, que o GNU/Linux ou Windows costuma ter por padrão abrir uns… chutando 65535 arquivos. Este valor não costuma ser fixo no GNU/Linux mas é baixo. E ai?
CRASHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHh.
Onde você vai aumentar este limite no GNU/Linux, Windows…?
-
Invista em Hardware.
Não adianta investir R$ 15.000,00 em um servidor e ele ser uma droga.
Por exemplo: Aprenda que uma controladora de disco com cache via software e uma com cache real podem ser a diferença entre um SGDB lerdo e um que seja um avião.
E acredite tem muita empresa que compra servidores de R$ 15000,00 com controladora via software e vem perguntar: Não entendo comprei o melhor, porque a lentidão?
-
Seja mesquinho. Ajude no óbvio. Somente o que é fácil achar no tio Google. Mas guarde o que você leu nos manuais e em suas pesquisas para cobrar como consultoria.
Acredite que em 100 programadores pelo menos 99 não lê, não pesquisa, não te ajudará quando você precisar naquele problema complexo e está doido para pagar sua consultoria.
Porque somente sabem usar select, insert, update e echo “hello word”. Não querem perder tempo investindo na capacitação como você fez.
-
Depois disto poderá escolher qualquer SGDB. Todos irão trabalhar bem com bases grandes.
E de quebra poderá usar o Scriptcase pois você saberá as limitações dele, o que cobrar da netmake e quais POGS fazer em php puro para que tudo funcione bem.
Observações:
Não se preocupe em decorar o manual. Seu cérebro quando precisar irá indicar que existe a solução e onde encontrar. Algo do tipo: já vi isto em algum lugar e acho que é aqui.
Eu pessoalmente acho que o Scriptcase tem mais familiaridade com a tripa sertaneja, mas ele é um framework que possui abstração a dados então tem que ser bom com qualquer SGDB.
O detalhe é que nunca usei a tripa sertaneja nos meus projetos pessoais. Somente quando o cliente exige. Eu prefiro Firebird e Postresql.
Espero ter ajudado.
