MySQL: O Tipo de Dados JSON e o NoSQL

JSON é uma maneira prática, em formato texto plano, de trocar dados, independente, de linguagem de programação ou plataforma. JSON é como se fosse um arquivo CSV com esteróides, ou, um XML mais compacto. De tempos em tempos, surge uma evolução de arquivos, protocolos, ou, formas de troca de dados. JSON é uma dessas evoluções.

O que significa JSON? Javascript Object Notation… Hum… se tem java no nome… Disse uma vez um monge tibetano que: “Java é a melhor forma de se criar uma aplicação que rode em qualquer plataforma, de forma mais lenta e com mais travamentos”. Sou técnico, e, não filósofo. Mas, o fato é que JSON (Djei Zon) já ganhou adeptos, e, é uma das formas de troca de dados entre aplicações, servidores, plataformas, etc. Portanto, merece um tipo de dados exclusive.

O MySQL implementou a tipagem, ou, tipo de dados JSON desde sua versão 5.7. Outros bancos de dados relacionais, também, implementam de alguma forma e/ou algum nível o formato (tipo) JSON. Mas, acredito que a melhor implementação, ainda, seja aquela feita pelo MySQL.

Algumas considerações técnicas sobre a implementação do JSON no MySQL:

  • As “strings” submetidas à uma coluna JSON são validadas, se, sua formatação não estiver de acordo com a RFC7159 será devolvido erro, e, os dados não serão persistidos na coluna;
  • As “strings” formatadas, que constituem um JSON, são convertidas para um formato interno binário que permite trabalhar com o JSON (agora chamado de documento). Isto, acarreta na possibilidade de indexação indireta, e, buscas mais inteligentes e rápidas;
  • Há uma série de funções que ampliam as funcionalidades à disposição dos desenvolvedores (e administradores de banco de dados);

Para quem estava em Scarif, nos últimos 5 anos, e, nunca viu um “Jason” em sua frente, ele se parece com isso:

{“Sakila Forever”, “8.0”, 2020, false, null}

Ou

{ “Product_ID”:  “0001”, “Name”: “Notebook XPTO”,  “Brand”:  “Apple”}

Note que, um documento ou “array” JSON, em última instância, não passa de uma “string”. Que pode, facilmente, ser formatada erroneamente. Por isso, o MySQL faz a validação dessa “string” quando ela é passada para uma coluna JSON.

Definição Teórica: Uma “string” ou documento JSON, consiste em uma série de pares conhecidos como Chave/Valor. Sendo que, a Chave é separada de seu valor por dois pontos, e, cada par (ou conjunto) chave/valor é separado, dos demais, por vírgulas. Uma “string” completa ( documento, ou se preferir registro) é encapsulado entre chaves.

Aquecendo os motores, criaremos uma tabela com coluna JSON:

CREATE TABLE `JTable` (`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `JColumn` json DEFAULT NULL, UNIQUE KEY `id` (`id`));

Vamos testar o MySQL, para certificarmos que ele não aceitará “strings” mal formatadas:

INSERT INTO JTable VALUES (NULL, ‘Testando 1… 2… 3…’);

ERROR 3140 (22032): Invalid JSON text: “Invalid value.” at position 0 in value for column ‘MyJSON_table.JColumn’

 

Muito bom, a primeira vista, o MySQL recusou a “string” submetida à coluna JColumn (tipo de dados: JSON), pois, ela não pode ser transformada em um documento JSON válido.

Desta vez, vamos tentar com documentos JSON válidos (strings formatadas corretamente):

INSERT INTO JTable VALUES (NULL, ‘{“Product_ID”: “MEM1TB”, “Description”: “Memory Card 1TB”, “Group”: “Memory”}’);
Query OK, 1 row affected (0.00 sec)

INSERT INTO JTable VALUES (NULL, ‘{“Product_ID”: “HDD1TB”, “Description”: “Disk Drive 1TB 7200 RPM”, “Group”: “Disk Drives”}’);
Query OK, 1 row affected (0.00 sec)

 

INSERT INTO JTable VALUES (NULL, ‘{“Product_ID”: “HDD2TB”, “Description”: “Disk Drive 2TB 7200 RPM”, “Group”: “Disk Drives”, “Brand”: “Seagate”}’);
Query OK, 1 row affected (0.00 sec)

 

INSERT INTO JTable VALUES (NULL, ‘{“Available”: “YES”, “Online_Sales”: “YES”, “Description”: “Disk Drive 4TB 7200 RPM”, “Group”: “Disk Drives”, “Brand”: “Seagate”, “Product_ID”: “HDD472”}’);
Query OK, 1 row affected (0.00 sec)

 

INSERT INTO JTable VALUES (NULL, ‘{“Available”: “YES”, “Online_Sales”: “YES”, “Description”: “Disk Drive 4TB 10K RPM”, “Group”: “Open Box”, “Brand”: “Western Digital”, “Product_ID”: “HD41TB”}’);
Query OK, 1 row affected (0.00 sec)

Wow! Funciona mesmo! 

Percebam que nos dois primeiros “INSERTS” eu utilize as seguintes chaves: Product_ID, Description, e, Group.

Já no terceiro “INSERT”, mudaram as necessidades do negócio, e, inclui as chave: Brand.

Já no 5º e último “INSERT”, eu, propositalmente, mudei a ordem das chaves. Neste ponto, porque não associar chave com a nossa, boa e velha coluna?

Associar coisas novas com coisas conhecidas é uma forma muito utilizada para reduzir a curva de aprendizagem. E, não vejo problema em associar um documento ou “string” JSON a um registro, e, as chaves com colunas.

Bem-vindos ao maravilhoso e caótico mundo do NoSQL. Colunas são criadas a cada novo documento (linha ou registro). É um mundo no qual a normalização não faz sentido algum. Podemos ter 1000 registros, com, 1000 modelagens diferentes. Sem a necessidade de “ALTER TABLE”.

E o que acontece com os documentos (linhas ou registros) que não tem as novas chaves (colunas) implementadas? Preparado para a resposta? Cuidado… Não continue a leitura se não quiser ver sua vida mudada radicalmente:

Não acontece nada! (eu usaria outra frase, mas, a Oracle ficaria muito brava)

As linhas anteriores à implementação de uma determinada chave (coluna) seguem sua vida sem esta ou estas novas chaves.

Muito Bem! Nesse artigo aprendemos (eu espero que sim) sobre o que é um JSON, na teoria e na prática: como criar colunas JSON, e, como inserir documentos (linhas ou registros).

No próximo artigo iremos manipular estes dados.

Deixe um comentário

O seu endereço de e-mail não será publicado.

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.