sql - números - numeros ordinales hasta el 100

¿Beneficios de utilizar la notación de posición ordinal de SQL? (6)

Lo usaría:

Si adoras solucionar problemas
Creando consultas adhoc sin intellisense

No hay ventaja.

SQL Server solo es compatible con ORDER BY de todos modos. En cualquier otro lugar es una expresión para ser evaluada.

Información de fondo

La notación de posición ordinal, ordinales AKA, es una abreviatura de columna basada en el orden de las columnas en la lista de columnas de la cláusula SELECT , en lugar del nombre de columna o el alias de columna. Comúnmente soportado en la cláusula ORDER BY , algunas bases de datos (MySQL 3.23+, PostgreSQL 8.0+) también admiten la sintaxis para la cláusula GROUP BY .

Aquí hay un ejemplo del uso de ordinales:

GROUP BY 1, 2 ORDER BY 1, 2

No es bueno su uso porque hace que la consulta sea frágil: si el orden de las columnas cambia, los ordinales deben actualizarse o su consulta no devolverá lo que usted pensó que sería. Es muy probable que obtenga un error al usarlo en GROUP BY si las columnas en esas ubicaciones están incluidas dentro de los agregados ...

La pregunta

El único beneficio que puedo pensar es en menos datos para enviar a través del cable, si no está usando procedimientos almacenados o funciones (que hacen que el uso ordinal sea discutible, de todos modos). ¿Me faltan otros beneficios?

Revelación

Esto puede sonar como una tarea, pero en realidad es una investigación para un almuerzo educativo que la oficina realiza todos los meses. Pagan el almuerzo, tenemos que proporcionar un pequeño tema de interés.

Los dos casos de uso para mí son:

Tengo prisa y no quiero escribir, así que uso el ordinal. Siempre convertiría esto al nombre de columna para cualquier uso no temporal
la columna por la que ordeno es una larga sentencia CASE ; en lugar de volver a escribir la sentencia CASE para la cláusula ORDER BY , utilizo el ordinal que lo mantiene DRY . Hay formas de evitar esto, por ejemplo, usar CTE, subconsultas o ver, pero a menudo encuentro que el ordinal es la solución más simple.

Muchas veces cuando consulto una tabla con muchas columnas (en ad-hoc-land solo para la exploración de datos ... nunca codificaría así para un entorno PROD) hago algo como esto para obtener campos que me interesan muy juntos:

select top 1000 Col_1, Col_18, Col_50, Col_117, * from TableWithTonsOfCols order by 1, 4 desc, 3

Si dije order by Col_1, Col_117 desc, Col_50 mi consulta sería incompleta porque la instrucción no sabría a qué columnas me refería pedir debido al "*" doblaje. No es muy común, pero sigue siendo una característica útil.

Si recuerdo correctamente, el uso de ordinales como usted describe está siendo desaprobado por Microsoft en una versión futura de SQL Server. Podría estar equivocado en esto, pero creo que ese es el caso. Siempre me ha gustado usarlos en ciertos casos porque implica menos tipeo cuando se trata de columnas derivadas que contienen una consulta larga.

Tengo un algoritmo de generación de consultas: el SQL se genera automáticamente. Usar el ordinal significa que puedo referirme al campo generado sin tener que recuperar el nombre del campo nuevamente. El usuario puede consultar el nombre del campo en una tabla seleccionándolo de una lista en la pantalla. Mientras haga que la lista corresponda con el sql, nunca necesitaría saber nombres de campo, si los elementos SELECT también eran ordinales.

La memoria dice que esto solía estar en el estándar SQL a fines de los 70

Tiendo a usar vistas en línea ahora:

select col_a, count(*) from (select case ...... end col_a from ...) group by col_a order by col_a;

Pero en los días previos a su sintaxis válida, ayudó a volver a escribir el texto completo de la columna. Con funciones complicadas, existían la posibilidad de discrepancias entre el valor en SELECT y ORDER BY, como

select ltrim(col_name,''0123456789'') from table order by ltrim(col_name,''123456789'')

El ''0'' en el SELECCIONAR significa que no estás ordenando por lo que seleccionas.