NoSQL: Os problemas de um termo infeliz

Hoje o meu amigo @epx141 escreveu o seguinte no Twitter:

#NoSQL is a typical confusion between API and backend implementation. SQL indeed sucks, but the storage engines behind it are great.
Instead of writing a new db from scratch, with 20 years of bugfixing ahead, why not take MySQL and make a better query language/API on top?
Elvis Pfützenreuter

O termo NoSQL é tão infeliz que levou o @epx141 a compreender de maneira totalmente inversa o que, de fato, é o tal NoSQL.

O que o @epx141 diz que é “great” (storage-engine, modelo de dados, etc) é justamente o que os desenvolvedores desses bancos de dados acham que “sucks”. E o que o @epx141 diz que “sucks” é justamente o que esses desenvolvedores gostariam de ter em seus bancos de dados (uma linguagem universal que explore bem as características de cada banco).

NoSQL é um termo infeliz porque os bancos de dados que fazem parte desse grupo não tem nada contra a linguagem SQL em si. Eles estão justamente ‘contestando’ a hegemonia do *modelo relacional* dos bancos de dados que, em sua imensa maioria, utiliza a linguagem SQL para manipular os seus dados.

Uma definição mais adequada para esse tipo de banco de dados deveria dizer algo similar à “bancos de dados não-relacionais”. Algumas pessoas, no Brasil, estão usando a sigla MRNN, mas não acho que esse termo ‘pegue’.

O termo NoSQL ‘pegou’ porque a linguagem SQL só faz sentido no contexto dos bancos de dados relacionais. Mas ninguém é contra a criação de uma linguagem ‘universal’ para manipulação de dados em bancos de dados não-relacionais.

O CouchDB até mesmo fez isso: usa REST, JS e MapReduce para manipulação dos seus dados. O MongoDB, criou uma variante do SQL. Já para Bancos de dados do tipo chave-valor talvez não faça muito sentido criar uma linguagem para acesso aos dados, afinal, esse tipo de banco de dados não passa de um ‘big dicionário distribuído, redundante, etc’.

O @epx141 é um cara que gosta do modelo relacional para bancos de dados. Ele também acha que eu não gosto. A minha opinião é um pouco mais “cinza”: Eu acho que bancos de dados relacionais tem a sua utilidade mas ela, é muito menor que a utilidade de um banco de dados OO (ZODB, Caché, …) ou um banco de dados de documentos (CouchDB, MongoDB, etc).

É comum eu adotar uma postura ‘radical’ pra expressar essa opinião, mas a razão disso é justamente a de chocar e provocar a reflexão de uma manada de desenvolvedores que usa bancos de dados relacionais “por que sim”.

É óbvio que os bancos de dados não-relacionais ainda não dispõem da maturidade, robustez, etc, etc dos bancos de dados relacionais que existem hoje. É óbvio que ‘ninguém é demitido por usar RDBMS’. Mas não podemos nos esquecer de contextualizar as discussões.

Quando a IBM surgiu com a idéia do modelo relacional (Edgar F. Codd trabalhava para a IBM) os desenvolvedores torceram o nariz da mesma maneira. Os bancos de dados relacionais eram pavorosos e pouco maduros. O ciclo se repete agora.

Esse tipo de reação é freqüente no nosso mundo. É o medo da mudança. O medo do novo. Lembro de vários desenvolvedores Java falando da perfeição da sua linguagem/plataforma que hoje são referências no desenvolvimento Ruby. Tudo isso no tempo em que eu defendia o uso de Python (que, exceto pela sintaxe, é uma linguagem próxima de Ruby).

Precisamos ter em mente que a adoção de ferramentas (r)evolucionárias aumenta o risco dos projetos e que grandes riscos podem trazer grandes retornos (ou grandes prejuízos). O mundo da TI é muito cruel com os reacionários.