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

Question

SQL de CJ Fecha y relacional Teoría: Cómo escribir Precisa Código SQL , y él hace el caso que las consultas de posición son malos - por ejemplo, este INSERT:

INSERT INTO t VALUES (1, 2, 3)

En 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 es fuera de línea con el modelo relacional desde tuplas (filas) son conjuntos no ordenados de atributos (columnas). Estoy teniendo problemas para entender donde el daño es en la primera consulta. ¿Puede alguien explicar esto a mí?

Answer 1

La primera consulta se rompe casi cualquier momento los cambios de esquema de la tabla. La segunda consulta tiene capacidad para cualquier cambio de esquema que deja sus columnas intactas y no añade columnas defaultless.

Las personas que hacen consultas SELECT * y luego se basan en la notación posicional para extraer los valores que están preocupados son supervillanos de mantenimiento de software por la misma razón.

Answer 2

Mientras que el orden de las columnas es definido en el esquema, que en general no debe considerarse tan importante porque no es conceptualmente importante.

Además, significa que cualquiera que lea la primera versión tiene que consultar el esquema para averiguar lo que los valores están destinados a significar. 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 un poco diferente en este sentido -. Sin duda me entiendo la segunda versión mucho más fácilmente (suponiendo que los nombres de columna son sensibles)

Answer 3

No me importa acerca de los conceptos teóricos en este sentido (como en la práctica, una tabla sí tiene a fin columna definida). La principal razón yo preferiría la segunda a la primera es un capa de abstracción añadido. Puede modificar las columnas en una tabla sin atornillar sus consultas.

Answer 4

Usted debe tratar de hacer sus consultas SQL dependen de la disposición exacta de la mesa lo menos posible.

La primera consulta se basa en la tabla sólo tiene tres campos, y en ese orden exacto. Cualquier cambio en absoluto a la mesa se romperá la consulta.

La segunda consulta sólo depende de la existencia de esos tres Felds en la tabla, y el orden de los campos es irrelevante. Se puede cambiar el orden de los campos en la tabla sin romper la consulta, e incluso se puede añadir campos, siempre y cuando permita valores nulos o tiene un valor por defecto.

A pesar de que no vuelva a organizar la disposición de la mesa muy a menudo, la adición de más campos de una tabla es bastante común.

Además, la segunda consulta es más fácil de leer. Se puede decir de la propia consulta cuáles son los valores puestos en el registro significa.

Answer 5

Algo que no se ha mencionado todavía es que a menudo va a tener una clave sustituta como su PK, con auto_increment (o algo similar) para asignar un valor. Con el primero, habría que especificar algo allí - pero ¿qué valor se puede especificar que si no se va a utilizar? NULL podría ser una opción, pero que realmente no encaja en la consideración del PK se establecería en NOT NULL.

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

Answer 6

SQL le da sintaxis para especificar el nombre de la columna, tanto para INSERT y SELECT. Debe utilizar esto porque:

• Sus consultas son estables a los cambios en el orden de la columna, por lo que el mantenimiento requiere menos trabajo.
• El ordenamiento columna se asigna a la mejor manera de pensar, por lo que es más fácil de leer. Es más claro para pensar en una columna como la columna "Nombre" en lugar de la segunda columna.

Answer 7

Yo prefiero usar la sintaxis UPDATE como:

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

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

Answer 8

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

Answer 9

Voy a añadir una cosa más, la segunda consulta es menos propenso al error originalmente incluso antes de que se cambian las tablas. ¿Por qué digo eso? Robaba con la forma seocnd puede (y debe al escribir la consulta) una inspección visual para ver si las columnas en la tabla de inserción y los datos de la cláusula de valores o cláusula select son, de hecho, en el orden correcto para empezar. De lo contrario puede terminar poniendo el número de seguro social en el campo Honorarios por accidente y el pago de los altavoces de su SSN en lugar de la cantidad que deben hacer para un discurso (ejemplo no elige al azar, salvo que hicimos atraparlo antes de que realmente ocurrió gracias a que comprobación visual!).