Durante algumas décadas, investiu-se na construção de bancos de dados orientados a objetos. A perspectiva era de que com um banco de dados orientado a objeto o mapeamento entre os dados e o banco, algo extremamente oneroso em bancos relacionais, pudesse ser transparente. De fato, muitos bancos foram criados durante as últimas décadas para atender à perspectiva orientada a objetos, no entanto sem muito sucesso. Uma das causas desse insucesso é porque cada linguagem trabalha com objetos de maneira diferente, sendo assim, seria necessário adaptar o banco para a linguagem específica que estivesse sendo utilizada. Outro problema é que as linguagens evoluem muito rapidamente, podendo transformar em obsoleto o mapeamento de dados pensado a 2, 3 anos. Com o amadurecimento de linguagens, como é o caso do C++ ou, mais recentemente, do JAVA, pode ser que bancos orientados a objeto voltem a ganhar força.
A tendência de criação de bancos NoSQL fez com que uma nova categoria de bancos surgisse. O document-oriented MongoDB é uma nova possibilidade que trabalha com o armazenamento de documentos no formato BSON, uma extensão do JSON que é muito conhecido entre os desenvolvedores JavaScript e largamente utilizado para a troca de informações na web. A principal diferença entre um documento JSON e um objeto em uma linguagem de programação orientada a objeto é que no JSON não é possível guardar métodos, no entanto permite guardar objetos e vetores – arrays – dentro de um objeto JSON.
Uma das grandes vantagens do MongoDB é justamente essa flexibilidade que o padrão BSON possibilita de se criar objetos dentro de outros objetos. Um exemplo de objeto armazenado no MongoDB é apresentado a seguir:
aluno = {“nome”:”Kelvin Santana”,”período”:5,”nascimento”:”1991-02-07”}
Como o formato BSON pode ser estendido, é possível acrescentar outras informações ao objeto aluno, de maneira que ele incorpore mais informações n o objeto criado, como um array de dados por exemplo.
aluno =
{
“nome”:”Kelvin Santana”,
”período”:5,
”nascimento”:”1991-02-07”,
“disciplinas pendentes”:[“Padrões de projeto”,”Administração de banco de dados”]
}
Também a adição de objetos completos é possível:
aluno =
{
“nome”:”Kelvin Santana”,
”período”:5,
”nascimento”:”1991-02-07”,
“celular”:{“ddd”:”31”,“numero”:”91233342”},
“residencial”:{“ddd”:”31”,”numero”:”25526123”}
}
Ou mesmo um array com objetos:
aluno =
{
“nome”:”Kelvin Santana”,
”período”:5,
”nascimento”:”1991-02-07”,
“telefone”:[
{“celular”:{“ddd”:”31”,“numero”:”91233342”}},
{“residencial”:{“ddd”:”31”,”numero”:”25526123”}},
{“empresa”:{“ddd”:”31”,”numero”:”37526137”}}
]
}
Todas essas estruturas são possíveis para o objeto aluno e elas podem coexistir em uma mesma Collection. A Collection é um conceito que se assemelha a uma Tabela em um banco de dados relacional. Uma Collection “alunos” pode receber todos os objetos “aluno” listados acima, mesmo que possuam características estruturais diferentes. Isso é possível por que cada Collection armazena documentos independentemente, ou seja, cada documento é independente de uma estrutura pré-fixada. O único item obrigatório para cada elemento é a chave “_id”, que é responsável por indexar todos os elementos de uma Collection e que é inserida automaticamente pelo MongoDB e que também pode ser inserida pelo desenvolvedor manualmente caso seja de interesse do mesmo.
Assim como uma tabela, é uma boa prática que a Collection armazene itens de um mesmo tipo básico, ou seja, a Collection “alunos” deve armazenar todos os alunos, sejam eles de graduação, ensino médio, básico ou pré-escola. Cada um desses tipos de alunos terá uma estrutura específica, como a divisão de notas e ou estrutura do curso – em semestres, anos, módulos –, mas também possuirá itens em comum. Ao procurar itens dentro de “alunos”, serão apresentados os Documents de todos os alunos cadastrados no banco. O Document é o equivalente a linhas em uma tabela de um banco relacional.
Quando usar?
Muitas pessoas entendem o conceito do MongoDB, mas ficam em dúvida sobre quando utilizá-lo. Os desenvolvedores do MongoDB – o pessoal da 10gen – pensaram o banco para ser algo dinâmico, em que cada Collection possa ser composta por diversos outros objetos. O exemplo clássico de quando utilizar o Mongo é um blog. Mas espera aí, quem é que constrói um blog hoje em dia? Algo pouco usual, ainda mais com o WordPress disponível. Então onde? Nesta sessão você verá alguns exemplos de quando usar e quando não usar.
Primeiramente será apresentado onde não usar o MongoDB. Se você precisa de um sistema que realiza várias ações atomicamente, como, por exemplo, uma conta no banco em que o dinheiro precisa ser creditado numa conta e automaticamente debitado em outra, não utilize o MongoDB. Ele não aceita ações atômicas em mais de uma Collection ao mesmo tempo. O mesmo serve se você está implantando uma loja virtual e precisa fazer o controle no estoque que está em outra tabela de maneira atômica em um não pode ser feito sem o outro. Neste caso, opte por outros tipos de banco, de volta aos famosos relacionais. Não entenda o fato do MongoDB não aceitar operações atômicas para múltiplas Collections – tabelas – ao mesmo tempo, como se o MongoDB não oferecesse atomicidade. Ele oferece sim, sempre que uma Collection for alterada e acontecer uma inserção, atualização ou deleção de quaisquer Documents no Mongo, esse processo será atômico.
Mas se a realidade do projeto é distinta da apresentada anteriormente, especialmente se você estiver em um projeto de software social – desenvolvido para suportar a interação entre diversas pessoas – como são os casos do Facebook, Twitter e de quase todas as empresas que querem que seus visitantes interajam com o seu site, o MongoDB foi feito para o projeto. Isso por que o mongo permite objetos multiestruturados. Sendo assim, se o seu sistema possui uma página e esta página possuir comentários ou seguidores ou pessoas associadas, provavelmente a solução em MongoDB será melhor projetada. Vale também para sistemas desktop que possuam estruturas de dados complexas e não requerem atomicidade entre diversas transações.
Um exemplo será apresentado a seguir. Imagine um sistema de organização de horário de uma faculdade em que será necessário distribuir as disciplinas entre os diversos professores e os professores entre os diversos horários. Em um sistema desses é muito comum possuir professores que tem restrições de dia, por exemplo, só podem dar aula às segundas e terças feiras e também possuem restrição de horários, nas segundas apenas no terceiro e quarto horários. As disciplinas possuem cargas horárias semanais, então certo número de aulas têm que serem ministradas durante a semana e cada disciplina pode ser ministrada por alguns professores, sendo que apenas um será escolhido para fazê-lo.
Uma organização para resolver este problema em um banco de dados relacional seria algo assim:
Esta solução foi feita da maneira mais simples possível para atender todos os requisitos listados acima. Em uma estrutura JSON, a solução seria um pouco mais simples, com apenas duas Collections.
Este é um tipo de sistema em que vale a pena optar pelo MongoDB.
Sistemas que necessitam fazer versionamento, ou seja, alguns usuários utilizam uma versão e outras utilizam uma nova, encontram no MongoDB uma alternativa perfeita para suportar o sistema. Isso por que como os Documents não precisam de estrutura fixa, os utilizadores de uma versão podem ter uma estrutura de dados e os de outra uma estrutura diferente, sem que isso cause qualquer inconsistência no banco e sem que você precise trabalhar com uma série de NULLS no tratamento de dados de qualquer uma das versões que estão no servidor. Basta disponibilizar a nova versão, atualizar os dados dos usuários que a utilizarão e pronto. Seu sistema já estará funcionando em modo multiversionado.
Por fim, o Mongo também oferece muita rapidez no acesso e a possibilidade de criar Shards de maneira muito otimizada.
Posteriormente será apresentado um pouco mais sobre o mecanismo de armazenamento de dados do MongoDB, como instalá-lo e utilizá-lo em aplicações cotidianas.