MySQL: O Tipo de Dados JSON e o NoSQL

O que é JSON?

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.

Quer saber mais? Entre em contato com a HTI!

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.

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

Entenda também: Banco de dados relacionais e não relacionais