MongoDB é schemaless. Mas o que isso realmente significa?

     Frequentemente, em um sistema relacional, temos uma tabela. E certamente possuímos colunas nesta tabela como, por exemplo, informações sobre a venda de um produto: código do produto, nome, quantidade vendida, nome do vendedor. As vezes, é necessário acrescentar alguma outra informação e, para isto, é necessário utilizar um comando do tipo ALTER TABLE, para adicionar uma nova coluna.

     No universo não relacional, com MongoDB, não é necessário fazer isto. Como este é orientado a documentos, cada um deles pode possuir um schema diferente. Isto faz com que o sistema seja facilmente adaptado conforme haja evolução, ou seja, necessária alguma mudança.Na prática, como fica?

     Vamos utilizar nosso exemplo da venda de um produto e criar uma collection chamada “produtos”

db.produtos.save ( { codigo : “a1” , nome : “Pacote Nordeste”, qtdeV : “2” , vendedor : “Jaime”})

e depois, visualizar esta collection de um modo mais elegante:

db.produtos.find().pretty()

     Agora, vamos supor que seja realizada outra venda, mas sem algumas informações:

db.produtos.save ( { codigo : “a2” , nome : “Pacote Sul”})

     Novamente, temos nossa collection:

     Vemos que os dois documentos possuem atributos distintos e é isto que torna o MongoDB muito mais ágil e o permite evoluir ao longo do tempo mais facilmente, pois é possível alterar o schema de um documento da seguinte maneira:

     Supondo que queremos alterar o produto com código “a2”, temos

var p = db.produtos.findOne({codigo : “a2”})

e para acrescentar a informação de nome do vendedor basta fazer

p.vendedor = “Lucas”

e salvar a nova informação em nossa collection

     Fazendo agora uma nova consulta temos:

     Esta é uma das grandes vantagens de se construir um sistema utilizando MongoDB. Um dos grandes benefícios destes objetos dinâmicos é que migrações de schema tornam-se muito mais fáceis e, em um RDBMS tradicional, diferentes códigos podem conter scripts de migração de dados. Além disso, cada versão deve ter um script de migração reversa no caso de haver necessidade deum rollback.  Por fim, o comando ALTER TABLE pode ser muito lento e resultar em tempo de inatividade muito maior.

É isso pessoal. Até o próximo post!