{"id":682,"date":"2010-04-06T00:18:08","date_gmt":"2010-04-06T03:18:08","guid":{"rendered":"https:\/\/devkico.itexto.com.br\/?p=682"},"modified":"2010-04-06T00:18:08","modified_gmt":"2010-04-06T03:18:08","slug":"introducao-ao-mongodb-um-banco-de-dados-nosql","status":"publish","type":"post","link":"https:\/\/devkico.itexto.com.br\/?p=682","title":{"rendered":"Introdu\u00e7\u00e3o ao MongoDB: um banco de dados NoSQL"},"content":{"rendered":"

\"\"<\/a>J\u00e1 faz algum tempo que venho estudando o MongoDB.\u00a0 Dentro da turma dos SGBDs NoSQL este foi aquele com o qual acabei criando maior simpatia pela sua simplicidade e documenta\u00e7\u00e3o (apesar de muita gente falar do Apache Cassandra, sua documenta\u00e7\u00e3o ainda \u00e9 horr\u00edvel<\/strong>).<\/p>\n

O MongoDB \u00e9 um banco de dados orientados a documentos. Sendo assim, se voc\u00ea, assim como eu (e 99% dos desenvolvedores) v\u00eam de um ambiente dominado pelo modelo relacional, em um primeiro momento ver\u00e1 este SGBD como um alien\u00edgena – o que \u00e9 incr\u00edvelmente empolgante e assustador. Meu objetivo neste post n\u00e3o \u00e9 ensinar a usar o MongoDB (ser\u00e1 assunto do pr\u00f3ximo), mas sim expor as principais diferen\u00e7as entre este e o confort\u00e1vel modelo relacional.<\/p>\n

Este assustador (e maravilhoso) “mundo novo”<\/h2>\n

Para os acostumados com o modelo relacional, o MongoDB se mostrar\u00e1 assustador no primeiro contato porque a maior parte dos conceitos que nos forneciam uma certa sensa\u00e7\u00e3o de seguran\u00e7a basicamente “desaparecem”. Aqui \u00e9 obrigat\u00f3rio saber lidar com o medo: conforme mostrarei neste post, h\u00e1 riscos, mas os ganhos os compensam.<\/p>\n

N\u00e3o acho que o modelo n\u00e3o relacional possa ser aplicado a todos os casos, por\u00e9m \u00e9 sempre importante conhecer mais de um paradigma para que possamos no m\u00ednimo ampliar nossos horizontes quando nos deparamos com situa\u00e7\u00f5es que fogem da nossa zona de conforto (e o MongoDB pode ser bastante desconfort\u00e1vel neste primeiro momento).<\/p>\n

N\u00e3o h\u00e1 registros, mas documentos<\/h3>\n

Algo sempre me incomodou no modelo relacional: com ele tentamos representar o mundo real (que \u00e9 n-dimensional) usando uma abordagem bidimensional. Tudo o que eu for representar em minhas tabelas possui apenas duas dimens\u00f5es: linhas e colunas. \u00c9 verdade que podemos representar quantas dimens\u00f5es quisermos no modelo relacional a partir de relacionamentos, por\u00e9m sempre fica aquela sensa\u00e7\u00e3o de se estar “for\u00e7ando a barra”.<\/p>\n

Al\u00e9m disto, por mais bem feita que seja o processo de an\u00e1lise, sempre h\u00e1 a possibilidade de posteriormente mais um atributo ser encontardo. O mundo \u00e9 um ambiente complexo: acredito que para represent\u00e1-lo, precisamos tamb\u00e9m de uma terminologia complexa.<\/p>\n

No MongoDB, o equivalente aos registros s\u00e3o os documentos, que utilizam a sintaxe JSON. A melhor maneira de se ter um feeling<\/em> do que quero dizer \u00e9 ver o bicho. Sendo assim, observe o c\u00f3digo abaixo:<\/p>\n

\r\n\r\nKico = {\r\nnome: "Henrique Lobo Weissmann",\r\napelido: "Kico (ou seria este o nome?)",\r\ncidade: "Belo Horizonte"\r\n}\r\n\r\n<\/pre>\n
Eu criei um documento chamado kico <\/em>que possui 3 atributos: nome, apelido e cidade. Repare que em momento algum defini o tamanho m\u00e1ximo de cada atributo, regras de valida\u00e7\u00e3o ou qualquer tipo de restri\u00e7\u00e3o. Em seguida, se quiser armazen\u00e1-lo em um banco de dados, bastaria executar o c\u00f3digo abaixo:<\/p>\n
\r\n\r\ndb.kicodb.save(Kico)\r\n\r\n<\/pre>\n
Neste caso, eu estaria armazenando o documento Kico no banco de dados kicodb<\/em>. Agora, observe o c\u00f3digo abaixo:<\/p>\n
\r\n\r\nNanna = {nome:"Maria Ang\u00e9lica Alvares da Silva e Silva",\r\napelido:"N\u00e3nna",\r\nesposaDo:"Kico",\r\ncidade:{nome:"Belo Horizonte", estado:{nome:"Minas Gerais", pais:"Brasil"}},\r\ncaes:[{nome:"Fraude", ra\u00e7a:"Pinscher?"}, {nome:"Z\u00e9", ra\u00e7a:"Schnauzer"}]}\r\n\r\ndb.kicodb.save(Nanna)\r\n\r\n<\/pre>\n
Repare que um registro com estrutura completamente diferente foi incluida no banco de dados. At\u00e9 o atributo cidade \u00e9 diferente. Enquanto no registro “Kico” eu tenho apenas uma string, no objeto Nanna eu tenho um outro documento. Outro ponto interessante: repare que eu tenho inclusive uma cole\u00e7\u00e3o associada ao objeto Nanna.<\/p>\n
E tudo \u00e9 mesmo assim salvo no mesmo banco de dados sem problema algum. Na realidade, eu poderia armazenar at\u00e9 o registro abaixo sem problemas:<\/p>\n
\r\n\r\nesquisitao = {quantidade:34, poemaFavorito:"Batatinha"}\r\n\r\n<\/pre>\n
Como pode ser visto, n\u00e3o h\u00e1 regras de valida\u00e7\u00e3o r\u00edgidas: qualquer tipo de documento pode ser armazenado no banco de dados. Claro: na pr\u00e1tica somente objetos semelhantes s\u00e3o armazenados na base de dados, por\u00e9m \u00e9 bacana saber que se um dia aparecer algum novo atributo, poderemos inclui-lo apenas<\/strong> nos documentos aonde o mesmo \u00e9 necess\u00e1rio, ao contr\u00e1rio do modelo relacional, aonde uma coluna se aplica a todos<\/strong> os registros.<\/p>\n
Desvantagem:<\/strong> o desenvolvedor precisa ficar esperto para que suas bases de dados n\u00e3o virem um “samba do criolo doido”<\/p>\n
Vantagens:<\/strong><\/p>\n