PostgreSQL para administrar JSON
Mientras crea una tabla, tendrá dos opciones para su columna JSON. Tipo de datos JSON y tipo de datos JSONB, ambos tienen sus propias ventajas y desventajas. Revisaremos cada uno de ellos, creando una tabla simple con solo 2 columnas una identificación y un valor JSON. Después de esto, consultaremos los datos de la tabla y tendremos una idea de cómo administrar los datos formateados JSON dentro de Postgres.
Tipo de datos JSON
Creación de una tabla con el tipo de datos JSON
Creemos una tabla simple de dos columnas llamadas usuarios:
Crear usuarios de tabla (ID Serial no es una clave primaria nula,
info json no nulo
);
Aquí, la identificación de la columna actúa como la clave principal, y aumentará de manera incremental gracias a la serie de seudotipo para que no tendremos que preocuparnos por ingresar valores manualmente para ID a medida que avanzamos.
La segunda columna es de tipo JSON y se ve obligado a no ser nula. Ingresemos algunas filas de datos en esta tabla, que consiste en valores JSON.
Insertar en valores de usuarios (información) ('
"Nombre": "Jane Doe",
"Correo electrónico": "[email protected] ",
"PersonalDetails": "Age": 33, "Género": "F"
');
Insertar en valores de usuarios (información) (
'
"Nombre": "Jane Doe",
"Correo electrónico": "[email protected] ",
"PersonalDetails": "Age": 33, "Género": "F"
');
Puede usar su Beautifier/Minifier preferido para convertir las cargas útiles JSON anteriores en una sola línea. Para que pueda pegarlo en una solicitud de PSQL.
Seleccionar * de los usuarios;ID | información
----+------------------------------------------------------
1 | "Nombre": "John Doe", "Correo electrónico": "[email protected] "...
2 | "Nombre": "Jane Doe", "Correo electrónico": "[email protected] "...
(2 filas)
El comando seleccionar al final nos mostró que las filas se insertaron correctamente en la tabla de usuarios.
Consulta de Tipo de datos JSON
Postgres le permite cavar en la carga útil JSON y recuperar un valor particular, si hace referencia a ella usando el valor correspondiente. Podemos usar el operador -> después del nombre de la columna JSON, seguido de la clave dentro del objeto JSON. Haciéndolo
Por ejemplo, en la tabla creamos anteriormente:
----+----------------------------------------
ID | ?columna?
----+----------------------------------------
1 | "[email protected] "
2 | "[email protected] "
Es posible que haya notado las cotizaciones dobles en la columna que contienen correos electrónicos. Esto se debe a que el operador -> devuelve un objeto JSON, como presente en el valor del "correo electrónico" clave. Por supuesto, puede devolver solo texto, pero tendrá que usar el operador ->> en su lugar.
Seleccione Información ->> 'Correo electrónico' de los usuarios;ID | ?columna?
----+----------------------------------------
1 | [email protected]
2 | [email protected]
La diferencia entre devolver un objeto JSON y una cadena queda clara una vez que comenzamos a trabajar con objetos JSON anidados dentro de otros objetos JSON. Por ejemplo, elegí la clave "PersonalDetails" para mantener intencionalmente otro objeto JSON. También podemos cavar en este objeto, si queremos:
Seleccione Información -> 'PersonalDetails' -> 'Género' de los usuarios;?columna?
----------
"METRO"
"F"
(2 filas)
Esto puede dejarte ir tan profundamente en el objeto JSON como quieras. Dejemos esta tabla y creemos una nueva (con el mismo nombre) pero con el tipo JSONB.
Tipo de datos JSONB
Excepto por el hecho de que durante la creación de la tabla mencionamos el tipo de datos JSONB en lugar de JSON, todo lo demás aspecto lo mismo.
Crear usuarios de tabla (ID Serial no es una clave primaria nula,
info jsonb no nulo
);
Incluso la inserción de datos y recuperación utilizando el operador -> se comporta de la misma manera. Lo que ha cambiado está todo debajo del capó y notable en el rendimiento de la mesa. Al convertir el texto JSON en un JSONB, Postgres en realidad convierte los diversos tipos de valor JSON en tipo Postgres nativo, por lo que no todos los objetos JSON válidos se pueden guardar como un valor de JSONB válido.
Además, JSONB no preserva los espacios en blanco, el orden de las claves JSON según lo suministrado por la declaración de inserción. JSONB en realidad convierte la carga útil en binario nativo de Postgres, de ahí el término jsonb.
Por supuesto, la inserción de JSONB Datum tiene una sobrecarga de rendimiento debido a todos estos trabajos adicionales que Postgres debe hacer. Sin embargo, la ventaja que obtiene es en términos de un procesamiento más rápido de los datos ya almacenados, ya que su aplicación no tendría la necesidad de analizar una carga útil JSON cada vez que recupera uno de la base de datos.
JSON VS JSONB
La decisión entre JSON y JSONB SOLE depende de su caso de uso. En caso de duda use JSONB, ya que la mayoría de las aplicaciones tienden a tener operaciones de lectura más frecuentes que escriben operaciones. Por otro lado, si está seguro de que se espera que su aplicación realice más operaciones de escritura sincrónicas que leer, entonces puede considerar JSON como una alternativa.
Conclusión
Las personas que trabajan con cargas útiles JSON y diseñan interfaces para el almacenamiento de Postgres se beneficiarán inmensamente de esta sección en particular de su documentación oficial. Los desarrolladores tuvieron la amabilidad de proporcionarnos la indexación de JSONB y otras características interesantes que se pueden aprovechar para mejorar el rendimiento y la simplicidad de su aplicación. Te imploro que también investigres estos.
Con suerte, encontraste esta breve introducción del asunto útil e inspiradora.