Las bases de datos, las tablas, la normalización y un sólido plan de copias de seguridad nos permiten almacenar y mantener los datos.
Esas mejores prácticas combinadas, a su vez, nos permiten interactuar con esos datos. En el mundo actual impulsado por los datos, los datos son valiosos. Los datos no solo son valiosos, sino que a menudo son críticos para las soluciones de usuario final proporcionadas por productos y servicios. Extraer información, responder preguntas y métricas significativas de los datos mediante consultas y manipulación de datos es un componente integral de SQL en general.
PostgreSQL no es diferente.
Este quid fundamental es fundamental para el éxito en cualquier aspecto basado en datos.
A continuación, presento una combinación de 8 consultas diferentes o tipos de consultas que he encontrado interesantes y atractivas para explorar, estudiar, aprender o manipular conjuntos de datos.
No se enumeran en ningún orden de importancia.
La mayoría probablemente serán viejos amigos familiares. Quizás algunos se conviertan en nuevos conocidos.
Las tablas de muestra y los datos utilizados no son tan importantes como la construcción real de las propias consultas y lo que devuelve, ofrece o proporciona cada consulta. Muchos de ellos son simulados y derivados con fines de demostración y no deben tomarse literalmente en sus valores.
1. Unión izquierda, cuidado con los valores nulos a la derecha...
Supongamos que en este ejemplo, tenemos una venta activa de dos meses y obtenemos un total de ambos combinados.
Sin embargo, por alguna razón, el segundo mes no hizo todo lo posible y queremos apuntar a qué días el mes uno tomó el relevo.
Estas ventas se representan como pago de tablas y mes_falso para esta demostración.
A tener en cuenta:
- Solo comprobaremos los totales superiores a 2000.
- Limitaremos la salida a solo 10 filas.
Para empezar, tenemos esta expresión de tabla común (CTE) 'generando ' la tabla fake_month para nosotros, y la consulta que sigue.
dvdrental=> WITH fake_month AS(
SELECT setup::date
FROM generate_series('2007-02-01', '2007-02-28', INTERVAL '1 day') AS setup
)
SELECT date_part('day', p.payment_date)::INT AS legit,
SUM(p.amount),
date_part('day', fk.setup)::INT AS fake
FROM payment AS p
LEFT JOIN fake_month AS fk
ON date_part('day', fk.setup)::INT = date_part('day', p.payment_date)::INT
GROUP BY legit, fake
HAVING SUM(p.amount) > 2000
LIMIT 10;
legit | sum | fake
-------+---------+------
1 | 2808.24 | 1
2 | 2550.05 | 2
6 | 2077.14 | 6
8 | 2227.84 | 8
9 | 2067.86 | 9
17 | 3630.33 | 17
18 | 3977.74 | 18
19 | 3908.59 | 19
20 | 3888.98 | 20
21 | 3786.14 | 21
(10 rows)Parece que ambos meses contribuyeron allí. Entonces, ¿esto está resuelto?
Antes de considerar esto resuelto, visitemos la cláusula ORDER BY.
Por supuesto, puedes ORDENAR POR ASC o DESC.
Sin embargo, también puede ORDENAR POR NULOS primero o último y eso cambia un poco las cosas.
Reescribamos esta consulta y usemos ORDER BY NULLS primero en la columna legítima.
Para abreviar, eliminaré el CTE de la salida, solo sé que todavía está allí y se está utilizando.
SELECT date_part('day', p.payment_date)::INT AS legit,
SUM(p.amount),
date_part('day', fk.setup)::INT AS fake
FROM payment AS p
LEFT JOIN fake_month AS fk
ON date_part('day', fk.setup)::INT = date_part('day', p.payment_date)::INT
GROUP BY legit, fake
HAVING SUM(p.amount) > 2000
ORDER BY legit NULLS first
LIMIT 10;
legit | sum | fake
-------+---------+------
1 | 2808.24 | 1
2 | 2550.05 | 2
6 | 2077.14 | 6
8 | 2227.84 | 8
9 | 2067.86 | 9
17 | 3630.33 | 17
18 | 3977.74 | 18
19 | 3908.59 | 19
20 | 3888.98 | 20
21 | 3786.14 | 21
(10 rows)No hay diferencia en absoluto.
¿Qué pasa si ORDENAMOS POR NULOS primero en la columna falsa? El de la derecha lado de JOIN?
Veamos.
SELECT date_part('day', p.payment_date)::INT AS legit,
SUM(p.amount),
date_part('day', fk.setup)::INT AS fake
FROM payment AS p
LEFT JOIN fake_month AS fk
ON date_part('day', fk.setup)::INT = date_part('day', p.payment_date)::INT
GROUP BY legit, fake
HAVING SUM(p.amount) > 2000
ORDER BY fake NULLS first
LIMIT 10;
legit | sum | fake
-------+---------+------
29 | 2717.60 |
30 | 5723.89 |
1 | 2808.24 | 1
2 | 2550.05 | 2
6 | 2077.14 | 6
8 | 2227.84 | 8
9 | 2067.86 | 9
17 | 3630.33 | 17
18 | 3977.74 | 18
19 | 3908.59 | 19
(10 rows)Ahora estamos llegando a alguna parte. Podemos ver que para los días 29 y 30, la columna falsa se ordenó desde la parte superior del conjunto de resultados.
Debido a ORDEN POR NULLS falsos primero.
Esto resuelve nuestra pregunta, hasta qué días se redujo la 'oferta 2'.
¿Te estás preguntando...
"¿Podemos simplemente filtrar con DONDE falso ES NULL? "
Así:
SELECT date_part('day', p.payment_date)::INT AS legit,
SUM(p.amount),
date_part('day', fk.setup)::INT AS fake
FROM payment AS p
LEFT JOIN fake_month AS fk
ON date_part('day', fk.setup)::INT = date_part('day', p.payment_date)::INT
WHERE date_part('day', fk.setup) IS NULL
GROUP BY legit, fake
HAVING SUM(p.amount) > 2000
LIMIT 10;
legit | sum | fake
-------+---------+------
29 | 2717.60 |
30 | 5723.89 |
(2 rows)Sí, eso funciona. Entonces, ¿por qué no usar esa consulta en su lugar? ¿Por qué es importante?
Siento que usar LEFT JOIN y ORDER BY NULLS primero para la tabla en el lado derecho de JOIN es una excelente manera de explorar tablas y conjuntos de datos desconocidos.
Al confirmar qué datos, si los hay, son "faltantes ' en ese lado de la condición de unión primero; mejora la claridad y la conciencia, lo que le permite filtrar los resultados establecidos con la cláusula WHERE
Por supuesto, la familiaridad con las tablas y los conjuntos de datos podría potencialmente eliminar la necesidad del LEFT JOIN presentado aquí.
Es una consulta valiosa para cualquiera que utilice PostgreSQL al menos intentarlo durante la exploración.
2. Concatenación de cadenas
La concatenación, la unión o adición de dos cadenas, proporciona una opción de presentación para los conjuntos de resultados. Muchas 'cosas ' se puede concatenar.
Sin embargo, como se indica en la documentación, el operador de concatenación de cadenas ('||') acepta entradas que no sean cadenas, siempre que una sea una cadena.
Veamos algunos ejemplos con las siguientes consultas:
postgres=> SELECT 2||' times'||' 2 equals: '|| 2*2;
?column?
---------------------
2 times 2 equals: 4
(1 row)Podemos ver que los números y las cadenas se pueden concatenar como se mencionó anteriormente.
El '||' operator es solo uno de los disponibles en PostgreSQL.
La función concat() acepta múltiples argumentos, concatenándolos todos al regresar.
Aquí hay un ejemplo de esa función en acción:
postgres=> SELECT concat('Josh ','Otwell') AS first_name;
first_name
-------------
Josh Otwell
(1 row)Podemos pasar más de dos argumentos si lo deseamos:
postgres=> SELECT concat('Josh',' ','Otwell') AS first_name;
first_name
-------------
Josh Otwell
(1 row)Notemos algo realmente rápido con estos siguientes ejemplos:
postgres=> SELECT CONCAT('Josh',NULL,'Otwell') AS first_name;
first_name
------------
JoshOtwell
(1 row)postgres=> SELECT 'Josh '||NULL||'Otwell' AS first_name;
first_name
------------
(1 row)
postgres=> SELECT NULL||'Josh '||'Otwell' AS first_name;
first_name
------------
(1 row)postgres=> SELECT CONCAT(NULL,'Josh','Otwell') AS first_name;
first_name
------------
JoshOtwell
(1 row)Observe que la función concat() ignora NULL sin importar dónde se coloque en la lista de parámetros, mientras que el operador de concatenación de cadenas no lo hace.
Se devuelve NULL si está presente en cualquier parte de la cadena para concatenar.
Solo sé consciente de eso.
En lugar de incluirlo manualmente dentro de la cadena que se va a concatenar, PostgreSQL también incluye una función concat_ws() que acepta un separador de cadena como primer parámetro.
Lo visitaremos con estas consultas:
postgres=> SELECT concat_ws('-',333,454,1919) AS cell_num;
cell_num
--------------
333-454-1919
(1 row)postgres=> SELECT concat_ws(' ','Josh','Otwell') AS first_name;
first_name
-------------
Josh Otwell
(1 row)concat_ws() acepta números o cadenas como argumentos y, como se indicó anteriormente, usa el primer argumento como separador.
¿Cómo trata concat_ws() a NULL?
postgres=> SELECT concat_ws('-',333,NULL,1919) AS cell_num;
cell_num
----------
333-1919
(1 row)postgres=> SELECT concat_ws(NULL,333,454,1919) AS cell_num;
cell_num
----------
(1 row)NULL se ignora a menos que sea el argumento separador dado a concat_ws().
Luego, todos los argumentos se ignoran y en su lugar se devuelve NULL.
La concatenación es genial...
Ahora que tenemos una idea de cómo funciona la concatenación, veamos un par de ejemplos.
Volver a la base de datos de alquiler de DVD simulados
Supongamos que necesitamos compilar una lista de los nombres y apellidos de los clientes, junto con su dirección de correo electrónico para enviar una nota para actualizar su cuenta.
Limitaré la salida a solo 10 filas por razones de brevedad, pero seguiré demostrando el || operador.
dvdrental=> SELECT first_name||' '||last_name||'''s email address is: '||email AS name_and_email
FROM customer
LIMIT 10;
name_and_email
--------------------------------------------------------------------------
Jared Ely's email address is: [email protected]
Mary Smith's email address is: [email protected]
Patricia Johnson's email address is: [email protected]
Linda Williams's email address is: [email protected]
Barbara Jones's email address is: [email protected]
Elizabeth Brown's email address is: [email protected]
Jennifer Davis's email address is: [email protected]
Maria Miller's email address is: [email protected]
Susan Wilson's email address is: [email protected]
Margaret Moore's email address is: [email protected]
(10 rows)Tenga en cuenta que tuvimos que omitir las comillas simples que se usan con los apóstrofes y usar una comilla simple adicional para mostrar la posesión de la dirección de correo electrónico de cada cliente.
¿Por qué deberías saberlo?
Puede haber momentos en los que la concatenación de datos le presente una mejor perspectiva y comprensión del conjunto de datos con el que está trabajando. Junto con las opciones de generación de informes, la concatenación de conjuntos de datos compartidos con los de otros podría hacer que (los datos) sean más legibles y digeribles.
3. Suministro de lista de valores IN con subconsultas
Una Subconsulta tiene numerosos usos poderosos. De esos, proporcionar una lista IN de valores para verificar la membresía es común.
He aquí un uso rápido.
Supongamos que tenemos tablas de clientes y pagos en una tienda de alquiler de DVD simulada y queremos recompensar a nuestros cinco clientes con mayores gastos que alquilaron películas durante los días del 10 al 13 de abril.
Imagine que es un período objetivo especial. Entonces, si el cliente gastó más de $30, queremos reconocerlo.
Tenga en cuenta que hay otras opciones disponibles para resolver este tipo de preguntas (es decir, combinaciones, captura de resultados de selecciones múltiples, etc.), sin embargo, las subconsultas también pueden manejarlo.
Comenzaremos con todo el tinglado aquí. Esta consulta completa devuelve todo lo que queremos para esta pregunta en particular.
dvdrental=> SELECT first_name, last_name, email
FROM customer
WHERE customer_id IN (
SELECT customer_id FROM (
SELECT DISTINCT customer_id, SUM(amount)
FROM payment
WHERE extract(month from payment_date) = 4
AND extract(day from payment_date) BETWEEN 10 AND 13
GROUP BY customer_id
HAVING SUM(amount) > 30
ORDER BY SUM(amount) DESC
LIMIT 5) AS top_five);Este ejemplo en realidad contiene subconsultas anidadas, una de las cuales es una tabla derivada.
Empecemos profundizando en la subconsulta más interna, esa tabla derivada.
Esta subconsulta es una instrucción SELECT independiente en sí misma, que devuelve un id_cliente y un SUM() en la columna de cantidad.
Solo aquellos clientes que cumplan con los criterios verificados por las cláusulas WHERE y HAVING hacen el corte, y se reducen aún más con LIMIT 5;
¿Por qué la siguiente subconsulta que preguntas?
¿No podemos simplemente usar la parte WHERE customer_id IN del SELECT más externo aquí?
Veamos con un enfoque práctico.
Eliminaré el AS top_five de la subconsulta y probaré la consulta más externa con él ahora:
dvdrental=> SELECT first_name, last_name, email
FROM customer
WHERE customer_id IN
(SELECT DISTINCT customer_id, SUM(amount)
FROM payment
WHERE extract(month from payment_date) = 4
AND extract(day from payment_date) BETWEEN 10 AND 13
GROUP BY customer_id
HAVING SUM(amount) > 30
ORDER BY SUM(amount) DESC
LIMIT 5);
ERROR: subquery has too many columns
LINE 3: WHERE customer_id IN (Aquí, la membresía de IN se está probando solo con la columna customer_id, pero la tabla derivada devuelve dos columnas y PostgreSQL nos lo informa.
Un remedio es usar otra subconsulta. Al seleccionar solo el ID_cliente del conjunto de resultados de la tabla derivada, se crea la siguiente subconsulta anidada interna.
Ahora, el predicado IN contiene varias filas de los valores de una columna para verificar la membresía con la cláusula WHERE para customer_id para establecer los resultados finales.
¿Por qué es importante?
El uso de subconsultas de esta manera es poderoso debido al número de valores que potencialmente podrían probarse con el predicado IN().
¿Imagina si hubiera un 100? ¿O más?
'Codificación rígida ' todos ellos en la lista IN() podrían volverse problemáticos y propensos a errores a medida que aumenta el volumen de valores.
4. generar_series()
Esta función de devolución establecida es práctica y muy divertida de usar y explorar. He usado generar_series() en los ejemplos anteriores, pero merece una charla propia. Centrándose más en la función y las capacidades.
Creo que generate_series() es útil para consultas comparativas en las que faltan algunos o todos los datos.
O solo hay datos parciales disponibles en el momento en que estoy explorando. Un uso útil es llenar tablas con 'datos ficticios '.
Para comenzar, crearemos una tabla simple:
trial=> CREATE TABLE tbl_1(
trial(> tb_id SERIAL PRIMARY KEY,
trial(> some_day DATE,
trial(> an_amt NUMERIC(4,2));
CREATE TABLELuego, use generate_series() como VALORES para nuestra declaración INSERT:
trial=> INSERT INTO tbl_1(some_day, an_amt)
VALUES(
generate_series('2018-04-01','2018-04-15',INTERVAL '1 day'),
generate_series(2.43, 34.20, 1.03));
INSERT 0 31Luego crea una segunda tabla
trial=> CREATE TABLE tbl_2(
tb2_id SERIAL PRIMARY KEY,
some_day2 DATE,
an_amt2 NUMERIC(4,2));
CREATE TABLEAdemás, rellénelo usando generate_series() en la instrucción INSERT:
trial=> INSERT INTO tbl_2(some_day2, an_amt2)
VALUES(
generate_series('2018-05-16','2018-05-31',INTERVAL '1 day'),
generate_series(15.43, 31., 1.03));
INSERT 0 16¿Por qué es importante?
Para reiterar, generate_series() es muy útil para crear datos simulados o de práctica.
Descubrí que imitar rangos de meses o días para comparar es excepcional con generate_series(). Consulte la sección 1 y el CTE allí, demuestra este uso.
Crear un conjunto de datos completos con generate_series() y compararlos con los datos almacenados para determinar si falta algún dato también tiene un gran valor.
5. Consulta con la función agregada COUNT() .
Esta función agregada simple pero efectiva debería estar en el arsenal de cualquiera. Especialmente al explorar tablas o conjuntos de datos por primera vez.
Quiero decir, ¿realmente quieres 'SELECCIONAR todo ' de una tabla con 1 millón de filas?
Determine con COUNT(*) cuántos registros hay antes de cargar.
Averigüemos cuántas filas tiene la tabla de películas en esta tabla de alquiler de DVD simulada:
dvdrental=> SELECT COUNT(*)
dvdrental-> FROM film;
count
-------
1000
(1 row)Si bien no es tan extenso como más de 1 millón de filas, estoy seguro de que ve la utilidad.
Para devolver el número de filas específicas, COUNT(*) se puede filtrar con una cláusula WHERE.
Veamos cuántas películas tienen una calificación de 'G':
dvdrental=> SELECT COUNT(*)
dvdrental-> FROM film
dvdrental-> WHERE rating = 'G';
count
-------
178
(1 row)Hay otra forma de COUNT() a tener en cuenta. COUNT(alguna_expresión) .
Las diferencias entre ellos son:
- COUNT(*) devuelve el total de todas las filas de entrada (incluidos NULLS y duplicados).
- COUNT(alguna_expresión ) cuenta el número de filas de entrada que no son NULL.
Cuando se usa junto con la palabra clave DISTINCT, COUNT() eliminará las entradas duplicadas y devolverá solo valores únicos.
Veamos eso en acción usando COUNT() con DISTINCT para determinar cuántos tipos únicos de calificaciones están presentes:
dvdrental=> SELECT COUNT(DISTINCT rating) FROM film;
count
-------
5
(1 row)Con esta consulta, sabemos que hay 5 tipos de calificaciones.
¿Por qué es importante?
Dependiendo de lo que se esté rastreando o apuntando, saber cuántos de algo existen puede ser importante. Por lo tanto, utilizar COUNT(*) o COUNT(some_expression ) ayuda con este tipo de desafíos.
Solo recuerda COUNT(*) no ignora NULL. Todas las filas, incluidos los valores NULL y duplicados, se devuelven como parte del número final.
6. ACTUALIZAR varias filas con una expresión CASE.
Supongamos que tenemos esta tabla:
trial=> SELECT * FROM reward_members;
rm_id | expense_amt | member_status
-------+-------------+---------------
1 | 1245.33 | gold
2 | 1300.49 | gold
3 | 900.20 | bronze
4 | 2534.44 | platinum
5 | 600.19 | bronze
6 | 1001.55 | silver
7 | 1097.99 | silver
8 | 3033.33 | platinum
(8 rows)Necesitamos cambiar el nombre de la columna member_status y agregar 'group ' al final del nombre actual presente para cada registro.
Para empezar, múltiples instrucciones UPDATE individuales lograrán esto sin problema.
Pero también puede hacerlo una sola expresión CASE.
trial=> UPDATE reward_members
SET member_status = (
CASE member_status
WHEN 'gold' THEN 'gold_group'
WHEN 'bronze' THEN 'bronze_group'
WHEN 'platinum' THEN 'platinum_group'
WHEN 'silver' THEN 'silver_group'
END
)
WHERE member_status IN ('gold', 'bronze','platinum', 'silver');
UPDATE 8Volvamos a consultar la tabla para ver los cambios:
trial=> SELECT * FROM reward_members;
rm_id | expense_amt | member_status
-------+-------------+----------------
1 | 1245.33 | gold_group
2 | 1300.49 | gold_group
3 | 900.20 | bronze_group
4 | 2534.44 | platinum_group
5 | 600.19 | bronze_group
6 | 1001.55 | silver_group
7 | 1097.99 | silver_group
8 | 3033.33 | platinum_group
(8 rows)Todas las actualizaciones fueron exitosas.
¿Por qué es importante?
Puede imaginar cuántos viajes de ida y vuelta tomaría esto al servidor si se hubieran ejecutado varias instrucciones UPDATE individuales. En verdad, solo 4 para este ejemplo. Pero aún así, el potencial para muchos siempre está ahí.
Sin embargo, al usar una expresión ACTUALIZAR con CASO, estamos enviando solo una consulta en su lugar.
7. COPIAR y \copiar
PostgreSQL proporciona COPY, un comando para exportar datos entre archivos y tablas.
Asegúrese de visitar el enlace proporcionado para ver la gran cantidad de opciones disponibles con COPY.
Una nota importante sobre COPY. Se requiere privilegio de rol SUPERUSUARIO para ejecutar este comando.
El meta-comando psql \copy es una alternativa para aquellos usuarios que no consideran este atributo de rol. Visitaremos ese comando en breve.
Primero, ejecutemos un comando COPY para exportar ciertas columnas a un archivo CSV en la máquina local.
Supongamos que tenemos este resultado de consulta para exportar:
trial=# SELECT expense_amt, member_status
trial-# FROM reward_members
trial-# WHERE member_status = 'gold_group';
expense_amt | member_status
-------------+---------------
1245.33 | gold_group
1300.49 | gold_group
(2 rows)Con COPY, podemos usar esa instrucción SELECT para completar esta exportación.
trial=# COPY (SELECT expense_amt, member_status
FROM reward_members
WHERE member_status = 'gold_group')
TO '/home/linux_user_here/awards_to_honor.csv'
DELIMITER ','
CSV HEADER;
COPY 2*Nota:según la documentación, la consulta debe estar entre paréntesis.
Ahora revisemos el contenido de ese archivo:
$ cat awards_to_honor.csv
expense_amt,member_status
1245.33,gold_group
1300.49,gold_groupPodemos ver que la primera línea contiene el ENCABEZADO (que son los nombres de las columnas) y ambas líneas tienen los datos Expense_amt y Member_status para ambas columnas devueltas por el filtro de la cláusula WHERE.
Otra advertencia importante que descubrí al ejecutar el comando COPY anterior.
El usuario debe tener privilegios para escribir en el archivo a nivel del sistema operativo.
En mi caso, arreglado con:
$ sudo chown postgres awards_to_honor.csvPuede evitar este problema escribiendo en un archivo del sistema al que el usuario actual tiene acceso, como /tmp (que se muestra a continuación).
trial=# COPY (SELECT expense_amt, member_status
FROM reward_members
WHERE member_status = 'gold_group')
TO '/tmp/awards_to_honor.csv'
DELIMITER ','
CSV HEADER;
COPY 2Sin embargo, uno de mis roles de prueba sin el atributo SUPERUSER tuvo problemas para escribir en el archivo /tmp.
Ver abajo para confirmación:
trial=# SET role log_user; -- changing from postgres user to log_user
SETAhora intenta el mismo comando COPY, escribiendo en la carpeta /tmp
trial=> COPY (SELECT expense_amt, member_status
FROM reward_members
WHERE member_status = 'gold_group')
TO '/tmp/awards_to_honor2.csv'
DELIMITER ','
CSV HEADER;
ERROR: must be superuser to COPY to or from a file
HINT: Anyone can COPY to stdout or from stdin. psql's \copy command also works for anyone.Quizás una mejor medida, como se sugiere en la SUGERENCIA:para roles sin el atributo SUPERUSUARIO, es el meta-comando psql \copy.
Realicemos un tipo de comando similar con \copy en lugar de usar el mismo rol, sin la necesidad de ese atributo SUPERUSER.
trial=> \copy (SELECT expense_amt, member_status
FROM reward_members
WHERE member_status = 'silver_group')
TO '/home/linux_user_here/more_awards.csv'
DELIMITER ','
CSV HEADER;
COPY 2No hay problemas allí.
Y el contenido de los archivos,
$ cat more_awards.csv
expense_amt,member_status
1001.55,silver_group
1097.99,silver_groupTambién funciona para la carpeta /tmp:
trial=> \copy (SELECT expense_amt, member_status
FROM reward_members
WHERE member_status = 'silver_group')
TO '/tmp/more_awards.csv'
DELIMITER ','
CSV HEADER;
COPY 2Mismo contenido presente en el archivo escrito también:
trial=> \! cat /tmp/more_awards.csv
expense_amt,member_status
1001.55,silver_group
1097.99,silver_group¿Por qué es importante?
La importación de datos a PostgreSQL a través de archivos es un método seguro de carga masiva. Aunque no todos están cubiertos en esta publicación de blog, COPIAR y \copiar ambos ofrecen varias opciones para trabajar con diferentes formatos de archivo y extensiones.
Del mismo modo, la exportación de datos de tablas o columnas específicas también se maneja fácilmente con estos dos comandos.
8. psql \help meta-comando
Está en una sesión de línea de comandos de psql. ¿Tiene curiosidad acerca de la sintaxis del comando CREATE INDEX?
No es necesario y va a un navegador u otro documento.
Prueba esto en su lugar:
trial=> \help CREATE INDEX
Command: CREATE INDEX
Description: define a new index
Syntax:
CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] name ] ON table_name [ USING method ]
( { column_name | ( expression ) } [ COLLATE collation ] [ opclass ] [ ASC | DESC ] [ NULLS { FIRST | LAST } ] [, ...] )
[ WITH ( storage_parameter = value [, ... ] ) ]
[ TABLESPACE tablespace_name ]
[ WHERE predicate ]Para saber qué texto de ayuda está disponible, puede ejecutar \help por sí mismo y obtener una lista de opciones disponibles.
No los enumeraré todos aquí, solo sepa que esa opción está disponible.
¿Por qué es importante?
El hecho de que este meta-comando sea súper fácil de usar, poderoso y conveniente son suficientes ventajas para mencionarlo aquí. Me ha ahorrado toneladas de tiempo dedicado a buscar en otra documentación. Y, por supuesto, siendo un novato, ¡lo uso con bastante frecuencia!
Conclusión
Esta no es una lista exhaustiva. Ni el 'be all end all ' de consultas y manipulación de datos.
Solo mi opinión sobre aquellos que despiertan mi interés y me hablan a medida que continúo aprendiendo y creciendo en un rol de desarrollador de SQL. Espero que a través de esta publicación de blog, encuentre casos de uso para las consultas y los comandos anteriores, implementando aquellos donde mejor le parezca.
