| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | No seguimento deste artigo surgiram-me umas dúvidas:
- Como vai o desenvolvimento da Firebird?
- PostgreSQL aproxima-se e distancia-se do MS SQL Server ou Oracle em que aspectos?
Para grandes frameworks de vários Terabytes compreendo a utilização de Oracle. Agora, para coisas mais pequenas, nomeadamente para soluções ligadas à internet (pequenas bases de dados de clientes, etc) será que se justificará MS SQL Server? Para além de abusivamente caro, e mesmo em tarefas que exigam bases de dados relacionais, o MySQL é uma óptima alternativa.
E já agora, será o futuro das BD's o xml?
Dominus vobiscum |
| | | | | | | - Como vai o desenvolvimento da Firebird? Bem e recomenda-se! O ano de 2003 foi um ano de continuo crescimento quer em número de utilizadores quer em membros aderentes à Fundação que suporta financeiramente o Firebird. Esta Fundação a exemplo do que está acontecer com outros projectos OS, constitui para mim a garantia dum crescimento sólido para um projecto que depende apenas da boa vontade de algumas dezenas de programadores. Recordo que com base nestes fundos são efectuados contratos mensais com programadores para que sejam efectuadas melhorias ou desenvolvidas novas funcionalidades bem como tarefas de teste e certificação do Firebird. Efectuou-se pela primeira vez um congresso na Alemanha (com Portugal representado) reunindo os principais programadores e estrategas do Firebird para sessões de esclarecimento bem como discussão do futuro do Firebird e que foi um sucesso. Paralelamente está em vias de ser lançada para muito breve a versão 1.5 (que já vai na Release Candidate 8) e que representa, embora com um desfasamento temporal muito grande da versão 1.0, um marco quer em termos de estabilidade e resolução de erros herdados da versão Interbase OS 6.0, quer em termos de novas funcionalidades (embora com carácter provisório ver Notas da Versão ou Factsheets) Não é também de menosprezar o cada vez maior número de ferramentas e drivers (ODBC,JDBC,.NET,Mono,DBExpress diversas Win32 API's, etc) que suportam o Firebird em diferentes plataformas. Finalmente salientaria o crescimento do suporte da Comunidade de Língua Portuguesa para o Firebird CFLP sedeada no Brazil com perto de 2300 membros. Quanto ao 2004 o futuro apresenta-se brilhante. Jim Starkey, pai do Interbase/Firebird, encontra-se em velocidade de míssil e após 20 anos a revolucionar o engine do Firebird por forma a simultaneamente responder aos desafios que o Hardware dos nossos tempos lhe coloca (64 bits, Multi-CPU's, Hiperthreading, Clustering) e ao mesmo tempo introduzir melhorias significativas na lógica do kernel. Estas melhorias visam alargar os já amplos horizontes, existem bases de dados a funcionar com centenas de utilizadores simultaneamente e com dimensões superiores a 40 Gb, para targets Oracle, Db2). È também pervísivel um impacto positivo resultante da união de esforços do Firebird com o Yaffil (versão igualmente nascida como fork do Interbase e muito popular na Rússsia) quer em termos de funcionalidades deste transportadas, quer em termos de adesão de novos programadores. Helen Borrie tem previsto para Maio o lançamento do primeiro livro do Firebird (parece pouco, mas a qualidade da documentação escrita por ela compensa largamente). Finalmente prevê-se que o 2004 acelere o ciclo de lançamentos de novas versões nomeadamente a aguardada 2.0, após um longo período, de organização, consolidação do software e preparação das bases para um crescimento sólido, 3 anos após o início deste projecto com base na velhinha versão 6.0 do Interbase. Como diria Jim Starkey "Long live the Firebird Republic!".
Carlos Mação
Membro do Projecto Marathon
Membro da Fundação Firebird |
| | | | Obrigado pelo esclarecimento!
Mas continuo com outra dúvida:
Que ganharia eu em usar Firebird e não MySQL/PostgreSQL?
Dominus vobiscum |
| | | | | Que ganharia eu em usar Firebird e não MySQL/PostgreSQL? Depende do tipo de aplicação que pretendes construir. No meu caso para desenvolvimento de aplicações ERP qualquer comparação entre o Firebird e as outras é pura perda de tempo o Firebird ganha em toda a linha. Se tivesse que desenvolver aplicações para Web em que o número de conexões é grande e de pequena duração, e com necessidade de querys rápidos, apesar de o PHP suportar o Firebird, neste momento optaria pelo MySQL, no entanto é bom relembrar que o MySQL não é gratuito para utilizações comerciais ao contrário do Firebird e do PostgreSQL. Na minha opinião para que o MySQL e o PostgreSQL consigam a estabilidade, maturidade e todas as funcionalidades que o Firebird possui há muito tempo ainda terá que decorrer algum tempo e aí espero que o Firebird já tenha conseguido a notoriedade que merece e colmatado algumas das suas lacunas actuais. Para ouvir algumas opiniões antagónicas aconselho a consultar este thread.
Carlos Mação
Membro do Projecto Marathon
Membro da Fundação Firebird |
| | | | Na minha opinião para que o MySQL e o PostgreSQL consigam a estabilidade, maturidade e todas as funcionalidades que o Firebird possui há muito tempo ainda terá que decorrer algum tempo
Importas-te de desenvolver mais um pouco? Que digas que o Firebird tem mais funcionalidades/maturidade que o MySQL concordo plenamente, mas na minha opinião o Firebird não está ao nivel do PostgreSQL.
Ou pelo menos foi esta a impressão com que fiquei quando o testei já há algum tempo atrás, acho que era a versão 1.0. Embora estivesse claramente a frente do MySQL no que diz respeito a funcionalidades não fiquei com essa sensação quando o comparei com o PostgreSQL. A situação pode já ter mudado e admito que a minha análise foi um pouco superficial mas acabei por escolher o PostgreSQL.
Se bem me lembro (e posso estar errado) o Firebird não é uma ODBMS, se bem me lembro também não tem tipos de dados array.
Não tenho nada contra o Firebird, muito pelo contrário, mas realmente achei-o inferior ao PostgreSQL, agradecia que me argumentasses a tua posição...
|
| | | | | Importas-te de desenvolver mais um pouco? Ok, começando pela maturidade o Firebird vem sendo usado em grande numero de produtos comerciais desde 1981 e o PostegreSQL apenas iniciou o seu desenvolvimento em 1986 quando nessa altura já muitas empresas faziam uso comercial do Interbase há 5 anos. Não esquecer também que durante estes anos todos até 2000 o suporte técnico foi feito por empresas de renome como a Ashton-Tate e a Borland. Em relação à funcionalidade diria que, salvo erro admissivel da minha parte pois o meu conhecimento do PostegreSQL é apenas exploratório, ou desactualização face à última versão: Não possui uma versão nativa (múlti-threads) para Win32.Não possui uma versão estável para WindowsNão possui 2-phase commit. Não possui Versão Embutida(embedded)Configuração complexa ao contrário do Firebird, que embora contendo um ficheiro de configuração nenhum desses parâmetros necessita de ser mexido para a quase totalidade das aplicações.Não possui character sets por campoMenor compatibilidade com a sintaxe do SQL-92/99(tenho dificuldade em defender esta afirmação, mas ela é unânime entre os programadores que usam as duas SGBD)Não possui limpeza automática de registos apagadosO Firebird possui o engine com menor tamanho e utilização de memória ou recursos de CPU, o que o torna adequado para palmtopsO Firebird ao contrário do PostgreSQL foi desenhado logo de princípio para não necessitar de qualquer intervenção em termos de manutenção ou administraçãoO Firebird possui a instalação mais fácil quer para ambientes Win ou nixAs bases de dados do Firebird são portáveis entre plataformas diferentesSei que algumas destas questões irão ser ultrapassadas em futuras versões, mas como já disse anteriormente quando o MySQL ou PostgreSQL lá chegar já o Firebird se encontrará procupado com utilizações mais avançadas como as do processamento distribuido. Para terminar diria que não conheço nenhum programador ou empresa que após experimentar o MySQL ou PostgreSQL e a seguir tenha experimentado o Firebird tenha retornado a qualquer destes. Como exemplo daria o caso da Compiere a maior ERP em Opensource a qual após experimentar o PostgreSQL o abandonou e encontra-se em negociações com elementos afectos ao Firebird para abandonar a actual dependência do Oracle. Para mim e a suportar a minha afirmação diria que para o desenvolvimento de ERP a ausência de necessidade de administração e existência de versões nativas para win32 e plataformas nix, ditaram a minha opção pelo Firebird. E até hoje não me arrependo. Mas esta é apenas uma opinião pessoal e subjectiva.
Carlos Mação
Membro do Projecto Marathon
Membro da Fundação Firebird |
| | | | Ok, obrigado.
Existiam de facto alguns factos que eu desconhecia, no entanto aproveito também para te esclarecer relativamente a alguns pontos que mencionaste:
Não possui uma versão nativa (múlti-threads) para Win32.
Não possui uma versão estável para Windows
Verdade, só utilizando o cygwin ou versões comerciais do PgSQL se tem uma versão Windows do mesmo, no entanto o suporte NATIVO para Windows já está a ser adicionado, na versão actual (7.4) esse suporte já existe numa forma muito rudimentar, é esperado suporte completo na proxima versão (8.0).
Configuração complexa ao contrário do Firebird, que embora contendo um ficheiro de configuração nenhum desses parâmetros necessita de ser mexido para a quase totalidade das aplicações.
Não considero a instalação/configuração do PostgreSQL particularmente dificil (./configure && make && make install),os valores de configuração pré-defenidos são bastante razoáveis, embora tenhas flexiblidade quando precisas dela.
Não possui limpeza automática de registos apagados
Isto era verdade até há bem pouco tempo, mas na versão actual (7.4) já tens o autovaccum.
O Firebird possui o engine com menor tamanho e utilização de memória ou recursos de CPU, o que o torna adequado para palmtops
Talvez, mas não considero o Firebird, nem o postgresql adequado para este tipo de uso, embora perca claramente em termos de funcionalidades quando comparado com qualquer um dos supra-citados acho o SQLite a escolha mais acertada para esse tipo de plataforma
O Firebird possui a instalação mais fácil quer para ambientes Win ou nix
Verdade, mas talvez essa dificuldade extra signifique também flexiblidade extra(estou pura e simplesmente a especular), além disso o facto do PostgreSQL ser mais unix-like agrada-me bastante.
Queria também salientar que não sou de forma alguma expert em nenhum dos dois estou apenas a expor as minhas conclusões obtidas de uma análise que fiz a ambos com o objectivo de escolher o SGDB para um projecto pessoal que estou a desenvolver (um sistema de gestão comercial para *nix/windows) que estou a desenvolver no meus (poucos) tempos livres
|
| | | | | Se bem me lembro (e posso estar errado) o Firebird não é uma ODBMS O Firebird é uma RDBMS que iniciou a translacção para C++ com a versão 1.5 e que considero só terá terminado esta tarefa com a 2.0. se bem me lembro também não tem tipos de dados array Incorrecto, mas existem outros tipos de dados presentes no PostgreSQL que eu gostaria de ter no Firebird como bit strings ou números de precisão arbitrária.
Carlos Mação
Membro do Projecto Marathon
Membro da Fundação Firebird |
| | | | Errata: onde escrevi ODBMS queria escrever ORDBMS (Object relational database management system).
Não percebi a tua resposta, eu estava-me a referir a possibilidade de uma tabela herdar outra tabela (o equivalente á herança multipla do C++ aplicado a uma base de dados).
É o único SGBD que conheço que implementa este conceito que acho de extrema utilidade nos mais variados casos, por ex. no software que estou a desenvolver nos meus tempos livres todos as tabelas de documentos fiscais (Facturas, Notas de Credito, Debito, VD's, etc) herdam a mesma tabela base que contem os campos comuns a este tipo de documentos o que facilita bastante a criação do mais variado tipo de relatórios (já não preciso de UNION xyz quando adiciono um novo tipo de documento pois o SELECT é feito a tabela base, retornado automáticamente todos os documentos).
Esta funcionalidade do PostgreSQL foi a que o tornou o vencedor da minha análise, nunca foi tão facil e rapido gerar um relatório de Movimentos ou uma conta corrente... só de pensar que no trabalho tenho de usar o Access como DB para um programa deste tipo err...
|
| | | | Única BD ORDBMS não comercial... as comerciais suportam isso há muito tempo. Mas custam dinheiro ;)
Cumprimentos
|
| | | | | É, tens razão quer acredites quer não quando estava a fazer o meu post estava a receber um sms a informar-me que tinha ganho um fin-de-semana grátis no Algarve! E não é daqueles de levar secas, mas sim dum concurso que ganhei. Fugiu-me o pensamento para o teclado.
Carlos Mação
Membro do Projecto Marathon
Membro da Fundação Firebird |
| | | | Boas.
"E já agora, será o futuro das BD's o xml?"
Em que sentido?
@419, Nbk
|
| | | | Não me parece... Isto é... O XML está e vai continuar associado às [O]RDBMS, mas não as vai substituir...
XML é porreiro para troca de dados... mas para armazenar... nah... o que cada vez mais vai acontecer é as BDs "falarem" XML, guardarem XML e pesquisarem XML
E haverá tb um nicho para BDs mesmo em XML.
NOTA: Se eu fosse adivinho estava à porta da Santa Casa a receber prémios... isto são só opiniões ;)
|
| | | | | XML nunca será o futuro, pois a performance dos 'parsers' deixa muito a desejar. E quando a quantidade de informação é grande, a maior parte dos SGBDs é simplesmente fantástica, na sua consulta e manipulação. XML é muito lento. :) A vantagem, é que o formato é legível, e não é preciso nenhum tipo de "cliente" para alterar um ficheiro XML e, em teoria, qualquer pessoa consegue consultar o ficheiro e perceber o que contém. Acho que XML é uma tecnologia boa, mas que nalguns casos é mencionado mais pelo hábito do que propriamente pela utilidade.
|
| |
|
