Aplicativos para a web, até poucos anos atrás, eram sinônimo de *PHP+MySQL*. Hoje em dia, há uma diversidade maior quanto as linguagens e frameworks utilizados _(embora o PHP ainda tenha muita força)_, mas poucos projetos saem do “padrão” do MySQL e, quando o fazem, fatalmente utilizam outros bancos de dados baseados em SQL, como o Postgree, Oracle, ou Microsoft SQL Server.

Este “padrão” empírico existe por um motivo bem simples – é gratuito e funciona bem. Porém, as necessidades evoluem – e bancos de dados baseados em SQL tem alguns sérios problemas em lidar com elas.

h2. Porquê implicar com o SQL?

Os bancos de dados que não utilizam SQL são considerados parte de um movimento chamdo *NoSQL*. Muitos desenvolvedores e analistas que apóiam este movimento acreditam na “morte” de bancos de dados utilizadores de SQL, possuindo poucos argumentos para justificar tal opinião além do fato destes bancos utilizarem SQL. Esta visão é errônea. Apesar do uso de linguagens de acesso a dados mais flexíveis que o SQL ser um benefício, os maiores problemas que estes novos bancos de dados tentam resolver tem a ver com outros aspectos.

Então, deve-se lembrar que os “bancos de dados SQL” são *transacionais, relacionais, dependentes de schema, e obedecem ao padrão ACID*.

h2. Qual é o problema?

Basicamente, o maior problema é que estes bancos de dados não lidam muito bem com a “web social”. Sites da web 2.0 – que permitem a participação e relacionamento ativo entre os usuários como parte integral de seu design – geram uma estutura conhecida como *gráfico social*. O gráfico social é um gráfico exibindo os relacionamentos de um usuário com outros usuários, itens e recursos do sistema.

!http://blog.memuller.com/uploads/social_graph-bible.png!
_Um gráfico social simples representando os relacionamentos entre personagens bíblicos._

Estes relacionamentos são de um tipo que não pode ser adequadamente representado através de um banco de dados relacional, principalmente em situações que exigem alto desempenho.

Pode parecer estranho dizer que bancos de dados relacionais não lidam bem com relacionamentos. De fato, eles são muito bons em representar relacionamentos um para muitos (1-n). Mas a maioria esmagadora de relacionamentos nos aplicativos modernos (e todos os envolvidos em um gráfico social) são de outro tipo, o muitos para muitos (n-n). RDBMS tem muita dificuldade em representar estes relacionamentos, requerindo tabelas intermediárias que complicam consideravelmente a arquitetura.

Várias outros atributos de RDBMSs podem gerar complicações – como a lentidão em escritas imposta pelo padrão ACID, a dificuldade de realização de sharding, a presença de schema, dificuldade de mapeamento de lógica de aplicativo para lógica declarativa, tamanhos de campos forçados, etc.

h2. Pensando diferente

Estas questões acima citadas não são problemas por padrão – são problemas somente na maioria dos aplicativos web atuais. Os bancos de dados SQL são excelentes para uma grande variedade de usos, então isso não é uma crítica a eles – e sim uma quieta admissão de que estamos usando a ferramenta errada para nossas necessidades, e precisamos pesquisar e entender novas formas de lidar com dados.

Uma abordagem interessante é representada pelos bancos de dados *orientados à documentos*. A principal característica destes é que, ao invés de armazenar objetos em uma tabela previamente estruturada – que define quais os atributos do objeto, seus tipos e tamanhos – cada objeto é armazenado como um *documento* separado, com *características*. As características não precisam ser uniformes entre os documentos, e cada característica pode armazenar várias informações.

Para fins de comparação, vamos observar como um banco de dados relacional armazenaria uma estrutura de usuários.

!http://blog.memuller.com/uploads/users-intranet.jpg!

Pode-se ver que é uma estrutura complexa, representando um problema típico: a estrutura precisa crescer, para conseguir armazenar dados que serão relevantes somente para um pequeno número de casos isolados.

Usuários em um banco de dados orientado à documentos podem ser representados da seguinte forma:

* *nome:* Bill, *setor:* TI, *atividades:* Analista de Sistemas, *celular:* xx-xxxxxxx

* *nome:* Anne, *setor:* TI, *atividades:* Analista de Sistemas, Consultora, *missão:* São José dos Campos, *fone-residencial:* xx-xxxxxxxx

Não há uma estrutura padrão para um usuário, logo, eles podem ter atributos diferentes. Não é necessário utilizar um atributo que um usuário não possui; atributos podem possuir mais de um valor. Na maioria dos bancos de dados, é possível, inclusive, inserir outros documentos inteiros dentro de um atributo.

h2. Na Canção Nova

Em função destas vantagens, o depto. de Pesquisa & Desenvolvimento de TI da Canção Nova realizou uma pesquisa extensiva, testando vários bancos de dados diferentes.

Concluímos que o “*MongoDB*”:http://mongodb.org/ atende melhor nossas necessidades, e o mesmo já está em uso em dois projetos. Bancos de dados que possivelmente serão utilizados no futuro incluem o “*Cassandra*”:http://cassandra.apache.org/ e o “*Neo4J*”:http://neo4j.org _(que usa um paradigma diferente – ele é um banco de dados gráfico)_.

Em um post posterior, vamos mostrar os resultados desta pesquisa, explicar a decisão, e descrever um pouco o *MongoDB* e nossos aplicativos que o utilizam. Até lá!