¿Por qué son malas las consultas de posición?

Question

estoy leyendo CJ Fecha de SQL and Relational Theory: How to Write Accurate SQL Code, y él hace el caso que las consultas de posición son malos — por ejemplo, este INSERT:

INSERT INTO t VALUES (1, 2, 3) 

su lugar, debe utilizar consultas basadas en atributos como esto:

INSERT INTO t (one, two, three) VALUES (1, 2, 3) 

Ahora, entiendo que la primera consulta está fuera de línea con el modelo relacional dado que las tuplas (filas) son conjuntos de atributos (columnas) no ordenados. Tengo problemas para entender dónde está el daño en la primera consulta. ¿Alguien me puede explicar esto?

Answer 1

La primera consulta se interrumpe prácticamente cada vez que cambia el esquema de la tabla. La segunda consulta acomoda cualquier cambio de esquema que deje intactas sus columnas y no agregue columnas sin valores predeterminados.

Las personas que realizan consultas SELECT * y luego se basan en la notación posicional para extraer los valores que les preocupan son software maintenance supervillains por la misma razón.

Answer 2

Realmente no me importan los conceptos teóricos al respecto (como en la práctica, una tabla tiene un orden de columnas definido). La razón principal por la que preferiría el segundo al primero es una capa de abstracción añadida. Puede modificar columnas en una tabla sin atornillar sus consultas.

Answer 3

Mientras que el orden de las columnas se define en el esquema, que generalmente no debería ser considerada tan importante porque no es conceptualmente importante.

Además, significa que cualquier persona que lea la primera versión debe consultar el esquema para averiguar qué significan los valores. Es cierto que esto es como usar argumentos posicionales en la mayoría de los lenguajes de programación, pero de alguna manera SQL se siente ligeramente diferente en este aspecto: ciertamente entendería la segunda versión mucho más fácilmente (suponiendo que los nombres de las columnas sean razonables).

Answer 4

Debe intentar que sus consultas SQL dependan del diseño exacto de la tabla lo menos posible.

La primera consulta se basa en que la tabla solo tiene tres campos y en ese orden exacto. Cualquier cambio en la tabla romperá la consulta.

La segunda consulta solo se basa en la existencia de esos tres campos en la tabla, y el orden de los campos es irrelevante. Puede cambiar el orden de los campos en la tabla sin interrumpir la consulta, e incluso puede agregar campos siempre que permitan valores nulos o tengan un valor predeterminado.

Aunque no reorganiza el diseño de la mesa con mucha frecuencia, es bastante común agregar más campos a una tabla.

Además, la segunda consulta es más legible. Puede ver a partir de la consulta en sí misma qué significan los valores puestos en el registro.

Answer 5

SQL le proporciona la sintaxis para especificar el nombre de la columna para las instrucciones INSERT y SELECT. Debe usar esto porque:

• Sus consultas son estables a los cambios en el orden de las columnas, por lo que el mantenimiento requiere menos trabajo.
• El ordenamiento de columnas se corresponde mejor con la forma de pensar de las personas, por lo que es más legible. Es más claro pensar en una columna como la columna "Nombre" en lugar de la segunda columna.

Answer 6

Yo prefiero usar la sintaxis UPDATE como:

INSERT t SET one = 1 , two = 2 , three = 3 

que es mucho más fácil de leer y mantener que los dos ejemplos.

Answer 7

A largo plazo, si agrega una columna más a su tabla, su INSERT no funcionará a menos que especifique explícitamente la lista de columnas. Si alguien cambia el orden de las columnas, su INSERT puede tener éxito silenciosamente al insertar valores en columnas incorrectas.

Answer 8

Algo que no se ha mencionado aún es que a menudo tendrá una clave sustituta como su PK, con auto_increment (o algo similar) para asignar un valor. Con el primero, debe especificar algo allí —, pero ¿qué valor puede especificar si no se va a utilizar? NULL podría ser una opción, pero eso no encaja realmente teniendo en cuenta que el PK se establecería en NOT NULL.

Pero, aparte de eso, el todo "vinculado a un esquema específico" es una razón mucho más importante, la OMI.

Answer 9

Voy a agregar una cosa más, la segunda consulta es menos propensa al error de manera original incluso antes de que se cambien las tablas. ¿Por qué digo eso? Debido al formulario seocnd, puede (y debe hacerlo cuando escribe la consulta) verificar visualmente si las columnas en la tabla de inserción y los datos en la cláusula de valores o selección están de hecho en el orden correcto, para empezar. De lo contrario, puede terminar colocando el número de Seguridad Social en el campo de Honorarios por accidente y pagando a los hablantes su número de seguro social en lugar de la cantidad que deben hacer para un discurso (ejemplo no elegido al azar, excepto que lo captamos antes de que sucediera realmente gracias a eso ¡Revisión visual!).