Estou passando a estudar Node JS e MongoDB. Estas duas tecnologias estão me conquistando e vou passar a utilizá-las profissionalmente. Com Javascript eu já estava acostumado, porém, banco de dados orientado a documento é novo para mim. Então este artigo vem a ajudar desenvolvedores que ainda estão se adaptando aos banco de dados orientado a documento que trazem o conceito de NoSQL(Not only SQL).

Andei pesquisando sobre normalização e banco de dados orientado a documento. Entrei perfisdiversos artigos na internet e estou passando a me acostumar a este novo paradigma. Percebi que normalização e orientação a documento não combinam muito bem. Mas, calma ai, isto não significa que é ruim. No mundo relacional vivemos querendo desnormalizar as tabelas para conseguimos performance nas diversas consultas que queremos fazer. O bancos orientado a documento oferecem formas de estar com os dados integrados e ainda assim, fornecer a respostas extremamente rápidas.

Sobre a integridade, umas das coisas que venho pensando bastante é sobre duplicidade dos dados e o relacionamento entre as coleções. Quais objetos merecem suas próprias coleções ? É viável manter uma coleção com tipos de dados diferentes, onde cada documento(um registro) pode ter campos diferentes? Quando começamos surgem estas diversas perguntas em nossa mente e isto nos atrasa porque temos que estudar bastante para poder projetar da forma correta. Andei pensando sobre e cheguei a algumas conclusões.

Algumas comparações com a estrutura de bancos relacionais: Objetos que podem ser utilizados em diversos cantos merecem uma coleção própria. Como exemplo relações N-N(muitos para muitos), ou 1-N(um para muitos). Os objetos que podem ser referenciado varias vezes em outras coleções, merecem uma coleção própria. No caso de relacionamentos 1-1, não vale a pena, uma vez que os documentos de uma coleção podem ter uma quantidade diferente de “campos”. Então como exemplo, se tivermos em um banco de dados relacional as tabelas usuarios e perfis, onde existe um relacionamento 1-1, não é vantagem ter duas coleções usuarios e perfis em um banco orientado a documentos. É mais interessante ter apenas uma coleção com todos os dados, mesmo que alguns registros(documentos) tenham mais campos que os outros, você deve tratar essa divergência no código.

Vamos utilizar por exemplo artigos(posts) e comentários. Temos um relacionamento 1-N. Penso que é inviável ter uma coleção apenas para os comentários. Pois, um comentário pertence apenas a aquele artigo, não será referenciado por outro artigo ou qualquer outro documento. Então, os comentários não merecem uma coleção própria e sim podem ser embarcados dentro da coleção de artigos. Apenas contendo uma referencia para o usuário que comentou. Ganhamos ainda em algumas operações, como na remoção do artigo que removerá os comentários deste em cascata. Na consulta por artigos não precisaremos de um INNER JOIN para trazer os comentários, pois estes já estarão embarcados no artigo, garantindo performance bem mais elevada que pesquisar em outra coleção.

Vejo que os bancos orientados a documentos vem oferecendo diversas vantagens. A escabilidade é a principal delas. Mas, também temos performance e linguagem de consulta simples. Podemos projetar rapidamente nossos dados e crescer sem muitas restrições e manter a performance em alto nível com muita simplicidade.

Para concluir e não estender muito o artigo. É isso, estou apenas iniciando vou pesquisar mais e mais, espero comentários de suas experiências, dessa forma podemos criar uma crítica minuciosa sobre como projetar nossos bancos orientado a documento.