Berkeley DB ganha uma API SQL
O Berkeley DB, que já hospedou os posts e comentários do BR-Linux até 2004, foi comprado pela Oracle em 2006, e desde então periodicamente recebemos notícias de novidades do produto – e dessa vez parece praticamente uma revolução, com a adição de uma API que permitirá o acesso e controle do banco via comandos SQL.
A razão parece fácil de entender: a nova API é similar à do também livre SQLite, usado em softwares como o Firefox, Thunderbird, Skype, Lightroom e IPhoneOS, e a Oracle provavelmente deseja uma fatia deste bolo – tanto que diz que agora todas as ferramentas para o SQLite funcionarão também para o Berkeley DB.
E há mais novidades, incluindo drivers ODBC e JDBC, e uma versão para Android, que se junta as anteriormente existentes para Linux, Windows, BSD, Solaris, Mac OS X, VxWorks e outros sistemas operacionais POSIX.
Outra novidade está no versionamento, que pula da versão 4 para a “11 g Release 2″, empatando com outros produtos da empresa. (via h-online.com)
@brlinuxblog
Feed RSS
Onde estão as viúvas do MySQL para criticar?
@ Conan
boa pergunta, hehe.
O gigante está se mexendo, ora. Mas eles ficaram um bom tempo sentados em cima desse banco sem grandes mudanças. O mesmo ocorrerá com o mysql, até que eles encontrem uma forma de ganhar tutu com o sakila.
O problema é que o mercado espera novidades rápido pois o mysql está claremente perdendo espaços por não poder dar respostas eficientes a problemas de escalabilidade.
Que heresia! Queimem no inferno!
“Mas eles ficaram um bom tempo sentados em cima desse banco sem grandes mudanças.”
Errado, sempre está tendo novidades. O Berkely DB evoluiu muito depois que foi adquirido pela Oracle.
O alvo do MySQL, na minha opinião, envolve sites pequenos, médios e até grandes. Se forem sites MUITO grandes (como um Twitter da vida), um banco de dados com modelo centralizado não dá conta do recado. As migrações acontecem de forma natural, e muitas aplicações começam minúsculas e vão inchando. E sim, o MySQL escala, dependendo do porte do projeto.
Não acho que ele esteja perdendo espaço no mercado. As pessoas interpretam errado porque o NoSQL está na moda, justamente por alguns sites de porte grande-enorme terem mudado para a arquitetura (que por sinal, não é nova). Acho o MySQL um excelente banco de dados onde aplicável, que na minha opinião só tem um problema mais evidente: não aceita chaves estrangeiras e buscas full text de forma nativa em um só engine. Nos projetos onde preciso desses dois recursos unidos tenho que recorrer ao PostgreSQL. Outro defeito do MySQL é que o manual é horrível e confuso. Já o manual do PostgreSQL é muito bom e objetivo.
Acho que sofremos no Brasil uma ‘mania de destro’. Aquela falsa idéia de que a mão certa para escrever é a mão direita, e que o canhoto é errado. Fico nervoso em ver soluções somente em banco de dados SQL quando a natureza dos dados são apenas em ‘key/value pair’, como por exemplo, login e senha. Há a menor utilizade de se usar um banco de dados SQL para armazenar login e senha. Duas informações previsíveis e indissociáveis. Ou seja, como se o modo ‘destro’ ou direito de armazenar dados seja sempre num banco de dados SQL, não importando a natureza dos dados.
Sem dúvida esta é uma ótima notícia acerca do BDB!
Quem trabalha extensivamente com Diretório OPenldap sabe que a questão da performance nem sempre é realmente boa, tendo até mesmo que recorrer a alternativas, como utilização do overlay back_sql e criação do banco para suportar esquemas TOTALMENTE manual!
Não quero entrar na questão do objetivo da oracle em investir no Berkeley mas espero que venha acompanhado de toda essa evolução que é realmente esperada dos vários produtos da empresa!
Fora o fato de várias soluções utilizarem o banco … (se não me falha a memória alguns deles são o Kerberos Heimdal, SVN, openldap …)
Kurt, não é só no Brasil, é no mundo todo. Veja o PHP, por exemplo… o banco que podemos dizer ser “padrão” dele é o MySQL, com o suporte nativo mais completo. PHP e MySQL são como feijão com arroz para desenvolvedores web, se considerarmos a popularidade da plataforma. SQL ainda é a solução mais conhecida e usada no mundo todo. Isso também é verdade para a maioria dos provedores de hospedagem. Neles a realidade é a do shared hosting, e dificilmente você vai achar provedores que suportem outra coisa que não seja MySQL ou bancos SQL. Eu não vejo problema em armazenar login e senha num banco SQL… inclusive tabelas são organizadas o suficiente para a maioria das situações práticas com dados. Não tem sentido é dizer que “não há utilidade”… tanto há quanto funciona perfeitamente.
Num mundo ideal e numa situação ideal concordo com você, as pessoas deveriam adotar soluções mais adequadas, dependendo do que querem fazer.
Ótima noticia, e tomara que seja mesmo muito compatível com o SQLite.
Kurt
“Fico nervoso em ver soluções somente em banco de dados SQL quando a natureza dos dados são apenas em ‘key/value pair’, como por exemplo, login e senha.”
Nervoso porque, acha tão difícil assim ? SQL precisa pouco estudo para começar, e não muito para saber utilizar bem.
Além disso, acho que está havendo distorção na interpretação da notícia. Pelo que eu entendi e olhei por alto agora nos manuais, o banco não está deixando de ser por key/value.
Vai continuar sendo assim, com OPÇÃO de acesso via APIs baseada no SQL. Peguem Java por exemplo, existe um mundo de aplicações já preparadas para lidar com interfaces JDBC, é todo um segmento que se ganha com o pouco esforço que deve ter sido feito para criar o driver.
Além disso, desde que quando a natureza dos dados é apenas key/value ?
Para alguns casos é muito melhor usar SQL.
Me inspiro em suas palavras:
Acho que sofremos no Brasil uma mania de novidade. Aquela falsa idéia de que quando surge algo novo, o modelo então vigentenão é apenas mais atrasado, é tido como completamente imprestável.
Menos, caaalma. MongoDB, CouchDB, Cassandra e semelhantes são muito interessantes. Mas usar achando que é a solução para todos os males da humanidade é perigoso.