Warning: fopen(logs/log_ouvindo_opinioes.txt) [function.fopen]: failed to open stream: No such file or directory in /home/storage/6/a1/fc/edudelphipage/public_html/includes/edp_log.php on line 6

Warning: fwrite(): supplied argument is not a valid stream resource in /home/storage/6/a1/fc/edudelphipage/public_html/includes/edp_log.php on line 8

Warning: fclose(): supplied argument is not a valid stream resource in /home/storage/6/a1/fc/edudelphipage/public_html/includes/edp_log.php on line 9
 EduDelphiPage - Ouvindo Opiniões | Qual Banco de Dados (SGDB) utilizar?

Ouvindo Opiniões

Qual Banco de Dados (SGDB) utilizar?

Opinião escrita por Kelver Merlotti

Sobre o autor: Técnico em Informática e Bacharel em Sistemas de Informações pela UNIFEV. É Coordenador Editorial do portal www.activedelphi.com.br e trabalha como programador na Mega Sistemas Integrados (www.megaonline.com.br). Atua na área de programação há 6 anos, focando-se na arquitetura client/server e web, com DBExpress, Firebird, PHP e MySQL.

Contato: kelver@activedelphi.com.br

Firebird e ponto! :-) Brincadeira... Deixe-me explicar: durante minha jornada como programador já brinquei com Interbase, Firebird, MySQL, Oracle e SQLServer (não contando os banquinhos do tipo paradox e Access). Sobre o PostgreSQL, vi muito pouco na faculdade e já não me simpatizei, por isso prefiro não opinar a respeito. Sobre os outros que já utilizei, posso resumir o seguinte sobre minha experiência com cada um:

- Interbase: utilizei até a versão 6.5, com pequenos projetos, até descobrir o Firebird :-). De lá pra cá, o IB evoluiu bastante, criando novos e interessantes recursos, mas, não o utilizei na prática, portanto, não posso dizer nada sobre ele atualmente. Naquela época deixava bastante a desejar! :-)

- MySQL: nem me arrisquei a utilizar outro banco em projetos web até hoje e ele deu conta do recado. De qualquer forma, não precisei em nenhum destes projetos web utilizar triggers, procedures, functions, etc.. Talvez por isso minha satisfação, pois, se tivesse precisado, ficaria na mão visto que estes recursos ainda estão amadurecendo no banco. Exceto este "detalhe", é um banco muito leve e de rápido processamento. Por isso seu tamanho sucesso na web.

- SQLServer: utilizei pouco e neste pouco que utilizei, não me pareceu valer o preço que pedem. De qualquer forma, parece ser um bom banco. Apesar de "pesadinho", possui recursos interessantes. Precisaria de mais prática com a "criança" pra dizer mais a respeito, por isso, paro por aqui sobre o SQLServer.

- Oracle: pau pra toda obra, mas que pau caro!!! O Oracle é muito robusto e não me lembro de nada que precisei que ele não tinha ou não deu conta de fazer. Também, pela idade que tem e o preço que custa, não poderia ser diferente. Entretanto, haja hardware!

- Firebird: ah, o Firebird! Paixão a primeira vista. Leve, mas robusto, open source, mas confiável. Pau pra "quase" toda obra. E esse "quase" só existe para "obras" que possuem "arquitetos" e "pedreiros" que não conhecem o Firebird, pois para se ter sucesso com o banco é preciso entender do otimizador de planos, a coleta de lixo existente pelo sistema de versionamento e principalmente como funciona o controle transacional. Não estudar estes pontos é dar tiro no pé e pedir pra não gostar do Firebird (em grandes projetos, obviamente, pois em projetos pequenos, isto acaba sendo indiferente).

Em resumo, escolher o banco de dados para um projeto não é simples. Muitas variáveis estão envolvidas, como: arquitetura (web, n-tier, client-server), quantidade de conexões simultâneas, quantidade de dados que será armazenado/processado, se haverá mais escrita ou mais leitura, hardware disponível para o servidor de dados, e principalmente, recursos financeiros disponíveis.

Em minha opinião, se for web, MySQL, exceto para projetos que terão grandes e pesados processamentos de dados e regras de negócios do lado servidor de dados, em background. Nestes casos, vale investir numa ferramenta que dê suporte para esta implementação, como o Oracle. O Firebird, neste, e somente neste caso, não ajuda muito, pois seu protocolo de comunicação AINDA não é leve o bastante para atender grande demanda na web.

Do resto, em tudo o FB atende com certeza! Mas obviamente se respeitarem na implementação do projeto as questões mencionadas acima (transações, planos de execução, garbage collection, etc).

Outro fator interessante e importante de ser lembrado é o seguinte: ninguém se arrisca a instalar um Oracle em uma máquina de pequeno porte, por saber que ele exige um hardware de qualidade. E por também saber que o FB é diferente, muitas pessoas colocam pequenos servidores com o Firebird para rodar grandes bancos, esperando que ele tenha o mesmo resultado, já que ele é um banco leve. Este é um grande erro! O Firebird é leve sim, mas, se o banco ou a aplicação é grande, não tem como fazer milagres. Ele também precisará de um bom hardware! ;-)

Comentários

Nenhum comentário foi feito ainda
 

"Ouvindo" Opiniões (as mais lidas)

Em breve, aguarde!!!

Pharetra Sed Tempus

Morbi sit amet mauris Nam vitae nibh eu sapien dictum pharetra. Vestibulum elementum neque vel lacus. Lorem ipsum dolor sit dolore phasellus pede lorem proin auctor dolor loremmassa phasellus sit. More…

Outras edições da Revista Active Delphi