“O que o VoltDB vem oferecer merece grande atenção: ele é diferente da maioria dos RDBMS atuais, que se baseiam em designs antigos de cerca de 30 anos atrás que apresentam alguns problemas de design quando o assunto é de performance e escalabilidade.”

Escalabilidade pode se discutir. Mas performance ?

Piada, estão muito bem. O que se quer é performance excelente com usuários Dummy que estão criando sua primeira aplicação em Basic, digo, PHP e mysql.

Achei estranha essa iniciativa. Muita promessa e tudo ligado a uma empresa só.

Prefiro esperar mais uns dois ou três meses a versão 9 do postgres que vem com muita novidade, principalmente na parte de escalabilidade, feita sem gambiarras.

Engraçado… Criador do Postgres lança um SGBD sob a GPL. Será que ele se revoltou com o modelo de licenciamento do pg?

“Engraçado… Criador do Postgres lança um SGBD sob a GPL. Será que ele se revoltou com o modelo de licenciamento do pg?”

Não sei. O que sei é que é um projeto completamente controlado por uma empresa.

Deve ter se revoltado é com a venda do Mysql. Pensado que se até aquele banco ruim foi bem vendido, porque algo muito melhor não pode.

Ainda bem que o postgres não é controlado por uma empresa. :)

http://www.voltdb.com/blog/key-value-benchmarking

@Weber Jr.

MySQL não é ruim. É MUITO ruim.
Tenho um projeto pessoal para fazer backup de arquivos em banco de dados. O suporte a BLOB do mySQL é a coisa mais porca e sem vergonha que que já ví.
Para começar tem 3 tipos de BLOB (Small blob, medium blob e large blob). Más são todos muito limitados. Usando ferramentas como essa, o desenvolvedor, mesmo que hobista como eu, acaba sendo obrigado a adotar as metodologias POG.
Tomara que a Oracle dê um jeito no MySQL. Do jeito que está, logo logo não vai ter mais niguem usando.

@Conan

Assim, não é uma boa prática usar o banco de dados para armazenar arquivos.

Ja vi excelentes sistemas funcionarem redondo sobre MySQL porém em muitas vezes alguma coisa foi sacrificada como a integridade referêncial (mas isso o ORM garante em varios casos, como no ActiveRecord do Rails). Porém usar banco, usar sql, para armazenar arquivos eu só faria em casos excepcionais e onde o tempo de leitura não fosse critico. Um bom cache e um filesystem eficiente (e bem configurado) é o ideal para 95% dos casos. Ai resta os outro 5% que o Conan pode estar enfrentando ;-)

@Conan

Acho muito dramático dizer que algo é “MUITO ruim” só por causa de uma funcionalidade secundária… Como outros disseram, banco de dados é para armazenar (preferencialmente) dados e não arquivos!

Quanto vai levar para a Oracle tentar comprar?

O PostgreSQL nasceu na Sum, e seu maior desenvolvimento também era realizado por eles, e acho que ainda é, só que agora são Oracle, como o MySQL, ou seja, estamos num terreno meio complicado ao falar desses dois SGBDs porque quem esta comandando é uma empresa que vive disso, o Oracle.

@Curioso

“O PostgreSQL nasceu na Sum”

Soma, é uma empresa ? Ou Sun ? Mas não interessa, não nasceu em nenhuma delas e sim na universidade de Berkeley(Não precisei consultar a Wikipedia pra saber isso :P).

“e seu maior desenvolvimento também era realizado por eles”

Não sei como mediu isso, mas duvido. A Sun ajudou muito, inclusive empregando alguns dos grandes desenvolvedores. Mas na última versão, por exemplo, muita coisa evoluiu no Pg e quase nada da Sun foi usado (faltou tempo nos testes, parece).

A versão 9 já está entrando em Beta com muita coisa nova (e por isso não vai mais ser 8.5 e sim 9) e a Sun já até é da Oracle.

“estamos num terreno meio complicado ao falar desses dois SGBDs”

Não, é muito diferente. Um banco é feito por uma empresa vendida e depois revendida num pacotão. Outro SGBD é feito por uma Organização independente que recebe sim, ainda bem, muita ajuda de empresas, diversas, não uma única.

Esses medos e achismos devem ser fruto ainda dos boatos maldosos e mentirosos (o velho FUD) que o Widenius andou espalhando para todo lado.

@Rodrigo Carvalho,
No meu trabalho eu estou acostumado com Oracle, vai ver que é por isso que eu acho que as fucionalidades existem para funcionar.

@SJCatar,
Porque não é uma boa prática armazenar arquivos em bancos de dadoss? Não é para isso que existe o tipo de dados BLOB? (Não é flame, eu não sei mesmo)

@Conan

Porque é muito mais eficiente armazenar arquivos no sistema de arquivos do SO, que foi feito especialmente para isso. Armazenar arquivos no banco de dados apenas incha o banco, tornando a execução das transações mais lentas desnecessariamente. Nesse caso a melhor opção seria armazenar o caminho do arquivo no banco de dados e os arquivos em si no sistema. Assim você consegue um sistema mais eficiente.

@SJCatar
“Armazenar arquivos no banco de dados apenas incha o banco, tornando a execução das transações mais lentas desnecessariamente.”

Na verdade isso depende muito do SGBD usado, SGBDS como o ORACLE permitem vc. usar este recurso sem impacto na performance.

@Víctor, vai ver que é por isso que bancos de dados tẽm este nome: armazenam dados. Já sistemas de arquivos, como o próprio nome diz, armazenam arquivos (poderiam ser chamados de bancos de arquivos?) hauahauha. Brincadeira, só pra descontrair :-)

Acho que o que o SJCatar quis dizer é que bancos de dados não foram originalmente feitos para o armazenamento de arquivos, mas de dados. Arquivo é um tipo especial de “contêiner” para armazenar dados, mas não é um banco de dados (embora bancos sejam normalmente armazenados em arquivos). São níveis de abstração diferentes.

Não sou muito expert em banco de dados (conheço no máximo um pouco de mysql e sqlite, só como usuário), mas o fato da Oracle ter um bom desempenho em armazenar arquivos não implica que um bom banco tenha que ter esta capacidade. Senão vira que nem o Corel Draw, um programa de criação vetorial que se destaca como preferido pelos usuários por recursos que não tem a menor relação com desenhos vetoriais. Logo qualquer programa que não faça tudo que o Draw faça não é considerado um programa tão bom.

Ah sim, eu descobri, por meio de um colega meu, que os blobs e binary blobs servem somente pra que os outros não consigam interpretar textos guardados nestes campos, e para quem futuramente for usar os dados tenham muitos problemas com codificação de caracteres… :-) hauhuhaau

Na verdade isso depende muito do SGBD usado, SGBDS como o ORACLE permitem vc. usar este recurso sem impacto na performance.

E tem alguns que trapaceiam. O MSFT SQL 2008, por exemplo. Muito se fala do gigantesco (da ordem dos petabytes) banco do projeto Pan-STARRS baseado num cluster de MSFT SQL Server 2008 (que a MSFT praticamente paga para que o usem). Só esquecem de dizer que os blobs com os dados/fotos em si são gravados fora do tablespace, em arquivos referenciados no sistema de arquivos. Apenas pegaram algo que seria feito na aplicação e colocaram como “feature”.