Hoje muito se fala de NOSQL (Not Only SQL) com um claro objetivo (pelo menos pra mim) que basicamente diz que nós não deveríamos colocar *TODO* o nosso dado em um banco de dados relacional (afinal como a galera anda dizendo, não existe bala de prata certo?), ou seja, é pensar mais na característica do nosso dado e tentar armazená-lo em um data store, digamos, mais apropriado. (Persistência poliglota?).
O que percebo na realidade é que as pessoas não entendem isso muito bem, não entendem o “NOSQL” (eu mesmo não entendia). Já fui a diversos eventos de tecnologia onde o tema foi abordado e sempre saia confuso, tentando encaixar o que alí tinha sido dito com a minha realidade, e de fato percebia o mesmo na cara dos demais e confirmava quando conversava com essas pessoas.
O problema é que sempre conseguimos encaixar tudo (qualquer tipo de dado) em um modelo relacional (em um banco de dados relacional) e sendo assím ficamos no mínimo ressabiados com qualquer abordagem “não relacional”, afinal foi o modelo relacional que aprendemos na escola e que sempre nos foi passado como “o cara”, são 40 anos utilizando este modelo ele realmente deve ser infalível (só que não).
Acredito que um ponto importante para toda essa dificuldade em entender ou aceitar modelos diferentes de dados esteja de fato no magnifico nome “banco de dados relacional“, embora não seja um nome errado isso gera confusão e um forte apego.
Os bancos de dados relacionais são baseados na teoria de conjuntos, lembram disso? Quem na faculdade não teve aquela famosa disciplina chamada álgebra relacional (forma de cálculo sobre conjuntos ou relações)? Tuplas, atributos, relacões… lembram??
Pois é o “relacional” dos bancos de dados relacionais não vem de relacionamentos e sim das relações, dos conjuntos ou como chamamos de maneira mais “moderna” das tabelas, é um banco de dados de tabelas onde aplicamos operações como: união, intersecção, diferença, produto cartesiano etc etc etc.
E se pensarmos como tal, deveríamos então deixar como responsabilidade para estes bancos de dados apenas dados com esta característica, dados tabulares.
Você já tentou modelar um domínio altamente conectado (tipo uma comunidade de pessoas) em um banco de dados relacional? Eu já e sofri com isso, modelar a gente modela certo? Tira as redundancias de dados (formas normais) e vai embora, mas e para tirar o dado de lá de dentro? Pois é, só sofrimento não é?.
Então vamos deixar a cargo dos bancos de dados relacionais o que eles são bons em tratar, dados tabulares, e vamos buscar outras alternativas para dados com outras características, beleza? Bora estudar meu povo! =D
Ahhh se tivessem me ensinando como banco de dados tabular eu não teria sofrido tanto… certamente não.