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:
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)
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.