Bruno Pereira

A Sun foi comprada pela Oracle. A EDS foi comparada pela HP anteriormente. Analisando o posicionamento atual, a HP DEVE estar pensando em comprar a Red Hat/JBoss. A aquisição da EDS não faz muito sentido sem uma oferta sólida de produtos. A Red Hat seria uma barganha para a HP, e daria à empresa um mercado enorme que ela ainda não possui. Para completar a pilha, poderiam levar de lambuja o EnterpriseDB, e ter um concorrente forte ao MySql que agora é da Oracle.

Acabei de saber do anúncio da compra da Sun pela Oracle, e posso dizer que fiquei muito surpreso. A Oracle é uma empresa que vive desde o começo de venda de licenças, e todo seu histórico de aquisições foi nessa linha, comprando empresas como a Peoplesoft, Siebel e BEA.

O que me intriga é que a Oracle não é tradicionalmente uma empresa de serviços. Ela costuma desenvolver e vender produtos, e a prestação de serviços é feita através de parceiros, como a Concrete por exemplo. Não consegui ter ainda a visão de como essa aquisição vai se encaixar dentro da estratégia da Oracle.

Não sei bem também como será a relação da Oracle com Open Source. A Sun não vinha tendo resultados financeiros muito bons, mas mantinha muitos projetos open source importantes, como o Glassfish, Solaris, MySql, stack SOA e vários projetos Java em geral. Além disso, desempenha um papel muito importante no desenvolvimento de linguagens dinâmicas para a JVM, além do desenvolvimento da própria JVM.

Se em termos de software tenho várias dúvidas, em relação às ofertas de hardware da Sun eu já consigo ter algumas idéias. Um dos principais concorrentes da Oracle é a IBM, que tem um braço bem forte de hardware. Não é raro a IBM ganhar concorrências com a Oracle “dando” o hardware, e vendendo o software. A Oracle não tinha condições de oferecer uma proposta equivalente, mas agora isso será possível.

Além disso, a Sun anunciou recentemente sua oferta de Cloud Computing, que pode ser um mercado que a Oracle quer entrar. Como ela já possui muitas aplicações críticas para empresas, ela pode querer oferecer estas aplicações como serviços, em uma estrutura de Cloud. Posso estar totalmente fora do alvo, mas não duvido que isto seja um objetivo da Oracle para diversificar seu modelo comercial.

Assim como em outras aquisições, muita coisa ainda não está clara, mas já temos vários aspectos para prestar atenção.

Hoje foi anunciado que a HP está comprando a EDS. O valor divulgado da compra é de US$ 13.9 bi.

Li algumas notícias dizendo que este movimento da HP tem como objetivo fortalecer a empresa para competir com a IBM. Entretanto, tenho sérias dúvidas se isso terá sucesso. A HP tem muita força na venda de equipamentos, e também presta serviços de manutenção de infra-estrutura. Já a EDS é uma gigante na prestação de serviços de software, tanto na área de manutenção de infra-estrutura como no outsourcing de aplicações, e consultoria de uma maneira geral. Como algumas áreas das empresas claramente se sobrepõem, imagino que muitos empregos serão cortados.

A HP passará a ter uma estrutura gigantesca, mas ainda ficará atrás da IBM em termos de faturamento. Além disso, embora fortaleça a empresa na disputa com a IBM, não fortalece tanto. A IBM tem uma área enorme de produtos de software que a HP continuará não tendo. Será muito difícil para a HP ganhar espaço contra a IBM sem um braço de software forte. Principalmente na área de middleware, onde a IBM está muito forte. E além da IBM, a HP teria que brigar também contra a Oracle neste nicho, depois que ela comprou a BEA.

É bom lembrarmos que a HP não tem lá um bom histórico em compras. A aquisição da Compaq foi bem traumática e não teve custo-beneficio muito bom para a HP. O mercado americano também não reagiu bem a essa compra da EDS. As ações de ambas as empresas caíram razoavelmente, mostrando que a maioria das pessoas do mercado não achou este negócio uma boa idéia para as empresas.

Na minha opinião, a HP após esta compra ainda é uma empresa incompleta para competir com a IBM, Oracle e Sun. Antes dessa compra a HP não era tida como concorrente direta dessas empresas, mas agora ela é. Penso que para a HP ter realmente relevância nessa disputa, ela precisará de um braço forte de middleware, e uma boa pilha de software em geral.

Com o histórico que a empresa tem, duvido que ela se transforme nisso por conta própria. Na minha visão o que faz sentido é a HP comprar mais alguma(s) empresa(s), para conseguir complementar suas ofertas de serviços. Considerando a consolidação atual do mercado, acho que faria sentido que a HP comprasse a Red Hat, levando o JBoss de lambuja. Além disso seria interessante que eles contassem com algum servidor de BD na pilha, já que os concorrentes possuem isso (DB2, Oracle e MySql). Uma ótima opção seria comprar a EnterpriseDB, que oferece uma versão comercial do Postgres, o excepcional BD open source.

De todas as grandes aquisições que rolaram recentemente, esta da HP é a que menos faz sentido, pelo menos atualmente. Dependendo das ações que eles tomarem em seguida, esta compra pode ser uma boa jogada ou um episódio lamentável como a compra da Compaq. Torço para que a HP aumente seus já fortes vínculos com Linux e Open Source e compre a Red Hat para se apresentar firmemente como competidora de peso. E claro, continuo torcendo pelo sucesso do meu estimado Postgres

Essa semana fiquei sabendo pelo blog do Savio Rodrigues que a IBM investiu US$ 10 milhões no EnterpriseDB, uma derivação comercial do Postgresql, mas cujos desenvolvedores atuam no desenvolvimento do produto open source também.

Com isso, até o momento o EnterpriseDB já recebeu no total US$ 37,5 mi, o que é bem próximo dos US$ 39 mi que o MySql havia recebido antes de ser comprado pela Sun. Torço para que isso ajude bastante no desenvolvimento do banco de dados e que eles consigam trazer ainda mais qualidade aos seus produtos. O Postgresql é um banco open source muito maduro e confiável já há muitos anos e o EnterpriseDB adiciona recursos interessantes para grandes empresas. Entre as principais forças do EnterpriseDB está a sua garantia de compatibilidade com código feito para o Oracle. Eles garantem por contrato que a sintaxe SQL, tipos de dados, packages, stored procedures, trigger e views desenvolvidas para o Oracle irão funcionar conforme esperado no EnterpriseDB. Isto sem dúvida é um facilitador para empresas que possuam grandes bases Oracle e queiram progressivamente migrar seus bancos de dados.

Eu usei pela primeira vez o Postgresql no começo de 2003, e sempre o considerei melhor que o Mysql. A principal razão pela qual o Postgres perdeu espaço para o MySql foi o fato de que o Postgres não tinha um instalador nativo para Windows antes da versão 8.0, que saiu em janeiro de 2005. O MySql tinha muito menos funcionalidades e confiabilidade, mas como era fácil utilizá-lo no Windows, sua adoção aumentou rapidamente.

Eu ainda considero o Postgres melhor do que o MySql e ele é o meu banco de dados preferido quando eu tenho a liberdade de escolher. Espero que eles continuem desenvolvendo bastante o produto e recebam mais investimentos. Eles merecem um ótimo lugar no mercado de bancos de dados, e torço para que eles consigam tanto ou mais sucesso que o MySql.

Aproveitando esta discussão, algo que me veio à cabeça diz respeito à consolidação das pilhas de produtos no mercado. Será que faria sentido que a Red Hat comprasse o EnterpriseDB e a Oracle comprasse uma distribuição Linux?

A Sun atualmente possui a pilha completa, indo do sistema operacional até o middleware Java, e inclui um banco de dados (MySql). A IBM não vende mais sistemas operacionais próprios (até onde sei), mas suporta bastante o Linux e tem seu banco de dados e o middleware Java EE.

A Oracle tem tudo menos o sistema operacional, especialmente depois da compra da BEA. A Red Hat tem tudo menos o banco de dados. Ambas fizeram compras significativas no passado. Será que veremos as 2 empresas completando sua pilha de produtos em breve?

Isto é algo que eu gostaria de saber, e seria bem interessante ver como o mercado se comportaria depois de tais movimentos.

Nos últimos meses trabalhei em uma boa diversidade de projetos, no trabalho, em projetos pessoais e artigos. Sem motivo nenhum especial, lidei nestes projetos com uma boa variedade de servidores de bancos de dados.

A maioria das coisas que faço no trabalho envolvem o Oracle, mas nos projetos pessoais utilizei o SQL Server, Postgresql, MySql e o Derby. 5 produtos diferentes, cada um com suas particularidades. Este convívio com diferentes bancos de dados me permitiu uma boa análise do momento em que já estamos em relação ao uso dos mesmos.

Na prática, basicamente o que mudava para mim de um BD para o outro era saber qual ferramenta de administração que eu deveria utilizar e qual driver jdbc precisaria baixar. Nos casos em que a camada de persistência era com jdbc diretamente (em vez de mapeamento objeto-relacional), eu precisava também prestar um pouco de atenção com pequenas diferenças na sintaxe SQL de cada um.

Algo que me chamou a atenção quando parei para pensar sobre isso foi que para a maioria dos projetos, qualquer servidor de banco de dados que eu utilizasse me atenderia sem problemas. Em termos de funcionalidades, o que eu preciso em um banco de dados não é nada sofisticado. Eu gosto de tratar do SGBD como um repositório confiável e eficiente para persistência de dados. Prefiro deixar toda a inteligência da aplicação fora do BD. O que eu espero de um bom servidor de BD é que ele mantenha os dados íntegros, ofereça recursos de restrições de integridade, índices, sub-queries e mais algumas funcionalidades nada extraordinárias.

Como falei, não gosto de colocar inteligência no banco de dados, então descarto o uso de stored procedures, triggers e coisas do gênero sempre que possível. A maioria dos SGBDs atuais suporta todos estes recursos que mencionei. Para a maioria das aplicações que desenvolvemos, o Oracle, Sql Server, DB2, Postgres ou MySql sem dúvida servem tranqüilamente. O conjunto de aplicações que tem acessos suficientes para derrubar qualquer um destes servidores é muito pequeno. Se na maioria dos casos qualquer SGBD serve, será que já podemos considerar os bancos de dados como commodities?

É claro que existem aplicações nas quais as exigências sobre o banco de dados são muito críticas. Alguns sistemas usam intensamente o servidor de banco de dados e possuem tabelas com milhões de registros que precisam de uma indexação muito eficiente. Embora talvez seja possível usar perfeitamente o Postgres e o MySql nestes casos, eu tomaria uma postura mais conservadora e só adotaria um dos 2 após diversos testes de carga sobre a aplicação usando eles.

Da mesma forma que existem aplicações que precisam de um servidor de banco de dados extremamente robusto, existem aplicações nas quais a praticidade de uso é o requisito mais importante. Temos por exemplo casos em que utilizar o Derby ou HSQLDB no modo embedded podem ser muito convenientes. É claro que o Derby e o HSQLDB não agüentam a mesma carga que os outros servidores mencionados. Todavia, a capacidade de empacotar o banco de dados dentro da sua aplicação pode ser muito conveniente, e nestes casos o Derby e o HSQLDB não poderiam ser substituídos por nenhum outro desta lista.

Nos casos em que os requisitos de banco de dados não são convencionais, algumas opções podem se mostrar muito mais adequadas do que outras. Entretanto, na maioria das aplicações, a troca de um produto pelo outro não fará muita diferença. Os recursos que realmente precisamos a maior parte do tempo estão disponíveis na maioria dos produtos.

A forte competição imposta pelos BDs open source fez com que os SGBDs comerciais passassem a oferecer versões gratuitas de seus produtos, com algumas limitações de uso. Para enfrentar este novo desafio, o Postgresql e o Mysql foram investindo cada vez mais esforço em seus produtos e hoje já têm uma ampla gama de recursos que antigamente só víamos em produtos comerciais. Com esta evolução do mercado, temos um largo leque de opções para escolher e estimo que em 90% dos casos, qualquer uma das opções atenderá plenamente.

Na minha opinião, isto já é suficiente para classificar os bancos de dados como commodities, na maioria dos casos. Já podemos ir na farmácia e pedir pelo genérico

Neste dia em que ficamos sabendo da compra do MySql pela Sun, acaba de ser divulgada também a compra da BEA pela Oracle!A compra da BEA pela Oracle está longe de ser uma surpresa, afinal a Oracle já havia feito uma tentativa anteriormente e sabemos que o Larry Ellison tem feito algumas aquisições marcantes de empresas, como a da Siebel e da Peoplesoft. Entretanto, isto ocorrer exatamente no mesmo dia da aquisição do MySql pela Sun não deixa de ser uma surpresa. Uma empresa muito forte em Java comprando uma empresa de banco de dados, e a fabricante do maior banco de dados do mundo comprando uma empresa fortíssima em Java. Momentos de consolidação no mercado.

Em relação à compra da BEA, espero que a abordagem da Oracle seja abandonar suas linhas de produtos Java e seguir a liderança da BEA nessa área. Os produtos Java da Oracle são infinitamente inferiores aos da BEA, e com esta compra teremos a Oracle com um novo braço tecnológico de muito vigor.

Uma aquisição deste porte ainda demorará algum tempo para demonstrar suas conseqüências, mas agora o pessoal da BEA terá poder financeiro para atuar ainda mais na vanguarda com seus produtos. Seus já excelentes produtos de SOA, BPM, Java e integração com certeza receberão investimentos maiores que os atuais e isto pode interferir nos rumos do mercado, pois agora a Oracle estará muito forte em áreas nas quais ela corria atrás dos outros players.

Muitas perguntas e incertezas surgem em função destas significativas aquisições de hoje, e uma pergunta interessante foi lançada pelo Savio Rodrigues : Quando a Oracle vai comprar a Sun? E pergunto eu: será que a HP não poderia comprar a Red Hat por exemplo?? Nesta consolidação do mercado, muitas coisas interessantes estão por vir. Como desenvolvedor Java, torço para que ambas as aquisições dêem ainda mais anos de sobrevida à plataforma e à linguagem Java. Let’s wait and see

Com a crescente adoção do uso de Linux, algumas pessoas têm me perguntado qual software de acesso a banco de dados eu uso no Linux. Eu utilizo um software que já conheço desde os meus tempos de desenvolvimento para PDAs, quando o DbVisualizer era a única forma conhecida de se acessar as bases de dados dos dispositivos móveis.O software pode ser baixado a partir daqui, após preenchimento de um pequeno cadastro. Para que usa distribuições baseadas em pacotes rpm, a opção do download do rpm é mais conveniente, e a instalação pode ser feita com o comando rpm –install nome_arquivo_dbvis.rpm. Para Linux em geral, pode ser utilizado o instalador em formato .sh

Baixando o instalador .sh, basta copiar o arquivo para um diretório qualquer de sua preferência e executá-lo como ./dbvis_linux_6_0_2.sh para iniciar o processo de instalação.

Caso o instalador não se inicie normalmente, verifique se o arquivo .sh está com permissão de execução (caso não esteja, faça chmod a+x dbvis_linux_6_0_2.sh) e se você possui o Java no PATH do seu usuário. Para verificar se você possui o Java e a versão do mesmo, use o comando: java -version. O recomendado é ter uma versão de Java da Sun e que seja a partir do 1.5. Muitas distribuições Linux instalam uma versão do Java da GNU, mas não gosto e não recomendo esta versão. Coloque o diretório do Java da Sun no começo do PATH do usuário (se alguém não souber como, eu explico posteriormente).

O processo de instalação em si é bastante simples. Você precisa apenas aceitar os termos de uso do software e escolher o diretório de instalação. No resto, aceite as opções padrão apresentadas e Next -> Next -> Next O processo de instalação cria um atalho no Desktop.

Com a aplicação instalada, vou mostrar agora como configurar a aplicação para conseguir acessar o Oracle. O driver jdbc do Oracle não vem incluído na instalação do DbVisualizer. Para conectar ao Oracle é necessário carregar o driver. Para isto, entre na opção Tools -> Driver Manager, conforme abaixo:

Nesta tela que abrir, selecione no menu esquerdo a opção Oracle Thin e então na janela que se abrirá, você terá que selecionar o jar do driver jdbc do Oracle (ojdbc14.jar ou classes12.jar), conforme abaixo:

Se o jar foi corretamente carregado, a opção do Oracle Thin aparecerá verde. Tendo feito isso é hora de criar a conexão. Vá para a tela principal da aplicação, e no menu esquerdo, clique com o botão direito na opção Connections e então escolha Create Database Connection. Escolha por não usar o wizard, e você chegará na tela a seguir:

Preencha os campos da seguinte forma:

• Alias: nome que você quer dar à conexão
• Database Type: Oracle
• Driver (JDBC): Oracle Thin
• Database URL: url jdbc de acesso, conforme será explicado abaixo.
• Userid: usuário de banco
• Password: senha do usuário

A URL jdbc varia de um servidor para o outro. No caso do Oracle, o formato é conforme publicado neste outro post. Como referência para o Oracle, se você tiver acesso a um tnsnames que acesse o servidor que você precisa, no tnsnames o formato da declaração é: nome_alias = string_conexao

Para criar uma URL jdbc do Oracle a partir de uma conexão declarada no tnsnames, você deve fazer jdbc:oracle:thin:@string_conexao

Pronto, após preencher este formulário de configuração, você está pronto para conectar-se ao Oracle! Caso alguma coisa não tenha ficado clara, por favor me indiquem para eu explicar melhor