Lançado o Firebird Database versão 2.0.2
“Esta disponível para download o Firebird Database versão 2.0.2, que contém correção de bugs e a implementação de algumas melhorias.”
Enviado por Anderson (anfa_rsΘyahoo·com·nr).
(postado por Augusto Campos)
Comentários dos leitores
Comentário de Dm7
24/08/07 23:10 - usuário registrado #2071
Comecei a estudar MySQL,: Comecei a estudar MySQL, aqui vai uma pergunta de iniciante: Como se diferenciam os dois em suas aplicações? Abs,
Comentário de builder
26/08/07 12:22 - usuário registrado #6750
Firebird e MySQL: O Firebird nasceu para ambiente desktop/rede interna (Fork do Interbase) e com maior suporte por ferramentas da Borland (atual CodeGear para IDE´s), buscando implementar recursos de SGBDS e ao mesmo tempo manter-se leve e rápido.
O MySQL é muito utilizado em sistemas WEB e com maior suporte por ferramentas voltadas para WEB (php por exemplo). O objetivo inicial do MySQL era ser um banco leve e muito rápido (e por consequência tinha menos recursos comparado a outros SGBDS).
Nos dias de hoje, eu diria que ambos estão muito semelhantes na questão de recursos (MySQL implementou vários recursos) e ambos podem ser utilizados ns mais diversas áreas, dependendo única e exclusivamente das necessidades mais peculiares do projeto em questão.
Os fatores mais determinantes para suas aplicações são:
Que recursos vou precisar do banco de dados (Integridade Referencial e outras constraints, Subselects, Unions, Views, Triggers, Stored Procedures, UDF (User Defined Functions),Suporte à transações, etc.) ?
Na questão anterior vai uma ressalva: Considere o crescimento natural da aplicação (complexidade e capacidade ao longo do tempo) para evitar uma migração prematura de SGBD.
Também não adianta escolher o banco de dados XYZ, cheio de recursos (e grande/pesado/complexo) se vai utilizar apenas o básico da SQL, que a maioria dos banco de dados tem e resolvem o problema da mesma forma. Resumindo: Não use um canhão para matar um mosquito.
A linguagem (ferramentas) que vou utilizar e o sistema operacional onde vou instalar possuem bom suporte ao banco de dados que vou utilizar ?
Tenho bons conhecimentos sobre o banco de dados (ou tenho ajuda de alguém que tenha conhecimento) para fazer as alterações necessárias e a manutenção ?
O processo de backup do SGBD esta bem definido e a cópia do backup (ter várias cópias, sem sobrescrever a última - grave em cd/dvd ou outra mídia - não use cd-rw/dvd-rw) é testada após sua realização (para verificar integridade). A questão aqui é simples mas fatal: Se o banco de dados e seus arquivos (seus dados) ficarem indisponíveis, estou apto a restaurar o sistema em tempo hábil e com a menor perda de informações possível ?
Dica: As mídias de backup ficam fora da empresa em local seguro (prevenção contra roubos, incêndios, atos de vandalismo, sabotagem, etc.)
O hardware para o banco de dados é adequado ? (só porque são leves, tem muito amador que coloca em pcs que não servem até para jogar paciência. O hardware deve ser de boa qualidade, confiável e com bom suprimento de energia elétrica (no-break).
A segurança é adequada (ou qualquer usuário pode resetar o servidor, apagar os dados, firewall inexistente, antivírus inadequado) ?
Se atender as questões acima, terá boas chances de ao final do dia dormir o "sono dos justos", ou seja, tranquilo e sereno, sem problemas.
Não adianta ter o super banco de dados XYZ se um simples reset/delete do usuário acaba com ele e seus dados.
O MySQL é muito utilizado em sistemas WEB e com maior suporte por ferramentas voltadas para WEB (php por exemplo). O objetivo inicial do MySQL era ser um banco leve e muito rápido (e por consequência tinha menos recursos comparado a outros SGBDS).
Nos dias de hoje, eu diria que ambos estão muito semelhantes na questão de recursos (MySQL implementou vários recursos) e ambos podem ser utilizados ns mais diversas áreas, dependendo única e exclusivamente das necessidades mais peculiares do projeto em questão.
Os fatores mais determinantes para suas aplicações são:
Que recursos vou precisar do banco de dados (Integridade Referencial e outras constraints, Subselects, Unions, Views, Triggers, Stored Procedures, UDF (User Defined Functions),Suporte à transações, etc.) ?
Na questão anterior vai uma ressalva: Considere o crescimento natural da aplicação (complexidade e capacidade ao longo do tempo) para evitar uma migração prematura de SGBD.
Também não adianta escolher o banco de dados XYZ, cheio de recursos (e grande/pesado/complexo) se vai utilizar apenas o básico da SQL, que a maioria dos banco de dados tem e resolvem o problema da mesma forma. Resumindo: Não use um canhão para matar um mosquito.
A linguagem (ferramentas) que vou utilizar e o sistema operacional onde vou instalar possuem bom suporte ao banco de dados que vou utilizar ?
Tenho bons conhecimentos sobre o banco de dados (ou tenho ajuda de alguém que tenha conhecimento) para fazer as alterações necessárias e a manutenção ?
O processo de backup do SGBD esta bem definido e a cópia do backup (ter várias cópias, sem sobrescrever a última - grave em cd/dvd ou outra mídia - não use cd-rw/dvd-rw) é testada após sua realização (para verificar integridade). A questão aqui é simples mas fatal: Se o banco de dados e seus arquivos (seus dados) ficarem indisponíveis, estou apto a restaurar o sistema em tempo hábil e com a menor perda de informações possível ?
Dica: As mídias de backup ficam fora da empresa em local seguro (prevenção contra roubos, incêndios, atos de vandalismo, sabotagem, etc.)
O hardware para o banco de dados é adequado ? (só porque são leves, tem muito amador que coloca em pcs que não servem até para jogar paciência. O hardware deve ser de boa qualidade, confiável e com bom suprimento de energia elétrica (no-break).
A segurança é adequada (ou qualquer usuário pode resetar o servidor, apagar os dados, firewall inexistente, antivírus inadequado) ?
Se atender as questões acima, terá boas chances de ao final do dia dormir o "sono dos justos", ou seja, tranquilo e sereno, sem problemas.
Não adianta ter o super banco de dados XYZ se um simples reset/delete do usuário acaba com ele e seus dados.