Fyracle: Banco de dados Firebird em modo Oracle

Que maravilha .Vou dar uma estudada no projeto .

Eu fico pensando na utilidade disso.
Se eu nao estou contente com o Oracle e preciso mudar para outro RDBMS livre, entao porque nao re-escrever diretamente para o banco alvo ?

Reescrever (ou adaptar) pode ser interessante, se você pensa em migrar uma aplicação sua e esta for uma solução aceitável. Melhor ainda seria fazer a aplicação independente do SGBD, se ela é sua.

Mas pense, entretanto, em outra situação: você precisa de um determinado aplicativo, e ele é compatível apenas com Oracle. Não ser obrigado a adquiri-lo (ou a abrir mão da aplicação) pode ser interessante.

Mas se voce pensar assim, nunca vai descobrir a verdadeira potencialidade dum RDBMS e vai ficar sempre perpetuando os aplicativos oracle-only.
Até vejo vantagens momentaneas e definitiva para alguns, mas esse tipo de opção como "generalização" é nocisa ao software aberto e só beneficia aos desenvolvedores Oracle e por fim a própria Oracle.

Não acho que seja a bala de prata para os desenvolvedores e para quem oferece suporte à implantação. Mas é uma alternativa a mais, principalmente quando (e se) tornar-se estável.

Na minha opinião, facilita a migração, e ainda permite ao desenvolvedor do tal aplicativo "Oracle-only" perceber que há demanda por alternativas.

Nem toda empresa usuária de aplicativos tem desenvolvedores aptos a adaptar o código feito originalmente para um banco de dados específico. Nem toda organização tem algum interesse em adaptar internamente o software que ela emprega. Poder implantar em um banco de dados livre (se for uma alternativa suficientemente sólida) pode ser bom para ela.

Reproduzir as interfaces e outras características é uma velha estratégia quando uma nova alternativa busca captar usuários de outra que é majoritária. As planilhas de cálculo do final da década de 80/início de 90 suportavam os comandos do Lotus 1-2-3 e do Visicalc, as primeiras versões do Word suportavam obrigatoriamente os formatos do Wordstar, suítes de escritório de hoje suportam os formatos do Microsoft Office, etc. Faz parte, e em muitos dos casos acima a estratégia foi bem-sucedida. Quantos usuários de Lotus 1-2-3 e Visicalc torceram o nariz para o Excel a princípio, mas quando precisaram usar resistiram menos ao saber que seus comandos e arquivos funcionariam corretamente, e depois acabaram adotando-o? Essa mesma sequência pode acontecer com o Firebird. Ou não.

Claro que isto dá a opção aos acomodados de simplesmente pararem por aí, mas os mesmos acomodados, atualmente (na situação descrita acima) possivelmente acabam simplesmente adquirindo o software proprietário de banco de dados ou adotando uma cópia não autorizada dele.

Outra vantagem é se você tem um sistema muito grande e o custo de portá-lo é muito alto. Essa seria uma forma de transição. Passamos por essa dificuldade atualmente onde trabalho.

Eu posso estar errado, mas vejo esta notícia sob uma ótica diferente, bem se foi possível "emular" o oracle, então também deve ser possível, fazer isso com SQL Server, Sybase e outros que existem por aí, conheço bem o Sybase pois trabalho com ele, uma licença OEM (só pode ser utilizada para o aplicativo com o qual ela foi comprada e nenhum outro) sai por US$ 160,00 por estação, imagina vc virar para a sybase e falar, olha só a sua maneira de trabalhar nunca me agradou, mas eu era escravo seu pois existim determinadas coisas que eu só conseguia fazer com o seu banco de dados, agora existe um outro banco de dados que faz exatamente tudo o que eu fazia com você. Como ficamos? quais são as vantegens que você nunca me deu que dará agora? ou seja existe a possibilidade de se quebrar a maneira como este mercado funciona hoje, e utilizando Software Livre ou Não esta mudança vem ocorrendo por pressão que o modelo do software livre vem fazendo no modelo dos softwares proprietarios. Posso estar enganado, mas vejo esta notícia desta forma.

Tenho algumas dúvidas, mas este porte que o teste se referiu, mas qual recursos estão sendo utilizados? PL-SQL por exemplo?
Tem detalhes que precisam ser analisados, a complexidade do banco também deve contar pois o Oracle tem algumas particularidades.
Imagino que tenha um nível maior de complexidade a medida que se aplique uma solução para mais pessoas.
O que vejo é o seguinte, muitas empresas tem "Oracle" e usam o básico, talvez nestes casos esta solução citada acima atenda. Mas em casos mais complexos, imagino que irá demorar uma eternidade e imagino que ficaria mais fácil criar um banco de dados novo do que simplesmente emular ( Com os devidos exageros :) ).
Eu não vi o artigo inteiro, postei baseado no resumo da noticia e nos comentários dos colegas.
É algo interessante, mas tem que se levar em conta vários aspectos técnicos.
Então moçada, nada de tirarem o seu Oracle, e se mandar para o Firacle.( risos )
Vamos aguardar os próximos capitulos.

PS: Um detalhe, estou usando o Postgresql e acho um banco fantastico, pelo menos até agora não senti falta do Oracle ( Apesar de saber que é um grande banco ).

Os detalhes sobre o Fyracle estão aqui: http://www.janus-software.com/fb_fyracle.html

Onde está o fonte?

Não achei o código fonte do Fyracle, no site acima só tem links para as versões binárias.
Estou certo ?

Pierre:
A princípio PL/SQL funciona. Somente tipos de dados (data type) não estão totalmente compatíveis. Não esquecendo que esta é uma versão beta.

Eu achei legal que os caras também tem um outro software, chamado Phoenix que é um basic orientado a objetos, RAD e que funciona em tanto win32 e linux.

PS: Prestem atenção no firebird. Ele vem crescendo rapidamente e, em termos de recursos, é o mais completo de todas as opções open-source. No sourceforge, ele aparece em 50o. lugar nos top downloads, perdendo apenas para o mySQL, 41o.

http://sourceforge.net/top/toplist.php?type=downloads

Há, para quem não sabe, firebird não está sob GPL e sim IPL.

http://www.ibphoenix.com/main.nfs?a=ibphoenix&s=1096309236:376886&page=ibp_ipl

"Oi", quanto aos tipos, imagino que os tipos raw (int, bigint, varchar, float, ...) e array nao é problema para ambos, mas quando um tipo for especifico demais do Oracle, no Firebird pode-se criar tipos (domains) que podem corresponder a uma variante raw.
Por exemplo, no FB nao existe o tipo boolean, mas voce pode criar o tipo boolean e dizer que o conteudo desse campo permite apenas 0 ou 1, ou "S" ou "N" :

create domain bolean as char(1)
check (value IN ('S', 'N')) NOT NULL;

isso nao é exclusividade do FB, o Sybase e MSSQL tambem possui isso na forma de constraint. Entao imagino que "tipos" não é um problema para rodar um oracle no FB mas outros aspectos de que nem todos precisam : 64bits, clusterizacao, etc... é que podem fazer a diferença.

Mas o maior problema na minha opnião é que quando as coisas funcionam direito poderá ocorrer acomodação no mercado, isto é, se minha aplicacao roda bem em oracle e pyracle pra que vou re-escrever em firebird, pg, ... nativamente ? Ou entao usar o Pyracle como testes antes de se tentar usar o oracle de verdade. Então a opção é bem vinda para os desenvolvedores, mas não é boa para o software livre no geral.
Soluções cross-plataform que parecem máginas tem de ser observados de uma forma mais cética possivel, o Kylix que prometia windows/linux nativamente serve de exemplo.

["Oi", quanto aos tipos, imagino que os tipos raw (int, bigint, varchar, float, ...) e array nao é problema para ambos, mas quando um tipo for especifico demais do Oracle, no Firebird pode-se criar tipos (domains) que podem corresponder a uma variante raw.]

Eu sei, só estava respondendo ao Pierre em que pé estava a compatibilidade.

Mas o maior problema na minha opnião é que quando as coisas funcionam direito poderá ocorrer acomodação no mercado, isto é, se minha aplicacao roda bem em oracle e pyracle pra que vou re-escrever em firebird, pg, ... nativamente ?]

Acomodação poque está rodando bem ? É claro. Que mal tem em rodar bem. Gaste seu tempo vendendo, criando novas soluções, melhorando seu produto, etc. Que mal há nisso ?

[ Ou entao usar o Pyracle como testes antes de se tentar usar o oracle de verdade. Então a opção é bem vinda para os desenvolvedores, mas não é boa para o software livre no geral.]

Duvido que algum desenvolvedor sério desenvolveria numa plataforma e venderia em outra. Isto é piada! É a mesma coisa que fazer um site de comércio eletrônico somente testando no firefox, sem testar no IE.

Não esqueças que são "patchs" aplicados em cima do código fornte do firebird 1.5.1 e não um fork.
Mas que tal se o firebird team quiser incorporar alguns destes "patchs" na próxima versão ? Não vejo problema nenhum de um banco de dados suportar características de outros. Quanto menos esforço houver durante uma fase de migração, melhor. Isto pode ser decisivo, podes apostar.

[Soluções cross-plataform que parecem máginas tem de ser observados de uma forma mais cética possivel, o Kylix que prometia windows/linux nativamente serve de exemplo]

Não vejo absolutamente nenhuma relação entre delphi/kylix e fyracle/oracle. Pense nisso como um produto que é compatível (em sintaxe e características) com o outro. Só isto.
Não vejo ninguém cético porque o open office lê documentos do ms-word ou o samba consegue compartilhar com máquinas windows, por exemplo.

Uma coisa é certa, aquele que desenvolve tendo em mente apenas um BD comete o mesmo erro, ou mais grave, de quem escreve aplicativos apenas para um sistema operacional.

Acredito que a estratégia é correta. Manter a compatibilidade com o Oracle é uma excelente abordagem. Vejo que reescrever "diferente" vários comandos deve necessariamente ser um aperfeiçoamanto dos existentes.
A compatibilidade com o Oracle em principio nos traz uma alternativa para a rápida migração das aplicações e a possibilidade de fornecer uma solução de baixo custo com qualidade.

A longo prazo, como bem observado pelo Augusto, as melhorias e implementações devem novamente "descolar" o fyracle do oracle e, nesse momento, espero que a confiabilidade, longevidade e outras características estejam maduras o suficiente para que a hoje opção possa ser uma escolha de fato.