registros - como insertar un campo en una tabla sql

Orden de fila predeterminado en la consulta SELECT-SQL Server 2008 vs SQL 2012 (1)

Nuestro equipo recientemente actualizó nuestras bases de datos de SQL Server 2008 a SQL Server 2012. Un cambio importante que notamos fue en el orden predeterminado de las filas devueltas por la instrucción SELECT, es decir, cuando no se especifica una cláusula ORDER BY explícita.

Según MSDN, SQL Server 2012 no garantiza el orden de las filas devueltas a menos que se especifique una cláusula ORDER BY.

Tenemos más de 2500 procedimientos almacenados en 5 bases de datos que tienen sentencias SELECT sin una cláusula ORDER BY y será un esfuerzo considerable agregar la cláusula ORDER BY manualmente para que coincida con el comportamiento en SQL Server 2008. ¿Existe una configuración o una forma más rápida de hacerlo? ¿esta?

La otra opción, que no se ha explorado, es degradar a SQL Server 2008. ¿Qué tan difícil sería?

Debe regresar y agregar cláusulas ORDER BY a su código porque sin ellas el pedido nunca está garantizado. Tuviste "suerte" en el pasado porque siempre recibiste el mismo pedido, pero no fue porque SQL Server 2008 lo garantizara de todos modos. Lo más probable es que tenga que ver con sus índices o cómo se almacenaron los datos en el disco.

Si se mudó a un nuevo host cuando actualizó la diferencia en la configuración del hardware solo podría haber cambiado la forma en que se ejecutan sus consultas. Sin mencionar el hecho de que el nuevo servidor habría recalculado las estadísticas en las tablas y el optimizador de consultas de SQL Server 2012 probablemente hace las cosas de manera un poco diferente a la de SQL Server 2008.

Es una falacia que pueda confiar en el orden de un conjunto de resultados en SQL sin indicar explícitamente el orden en que lo desea. Los resultados de SQL NUNCA tienen un orden en el que pueda confiar sin usar una cláusula ORDER BY . SQL se basa en la teoría de conjuntos. Los resultados de la consulta son básicamente conjuntos (o conjuntos múltiples).

Itzik Ben-Gan da una buena descripción de la teoría de conjuntos en relación con SQL en su libro Microsoft SQL Server 2012 T-SQL Fundamentals

La teoría de conjuntos, que se originó con el matemático Georg Cantor, es una de las ramas matemáticas en las que se basa el modelo relacional. La definición de Cantor de un conjunto sigue:

Por "conjunto" entendemos cualquier colección M en un conjunto de objetos definidos y distintos m (que se llaman los "elementos" de M) de nuestra percepción o de nuestro pensamiento. - Joseph W. Dauben y Georg Cantor (Princeton University Press, 1990)

Después de una explicación detallada de los términos en la definición, Itzik continúa diciendo:

Lo que deja de lado la definición de Cantor de un conjunto es probablemente tan importante como lo que incluye. Tenga en cuenta que la definición no menciona ningún orden entre los elementos establecidos. El orden en que se enumeran los elementos del conjunto no es importante. La notación formal para enumerar elementos del conjunto utiliza llaves: {a, b, c}. Como el orden no tiene relevancia, puede expresar el mismo conjunto que {b, a, c} o {b, c, a}. Saltando al conjunto de atributos (llamados columnas en SQL) que forman el encabezado de una relación (llamada tabla en SQL), se supone que un elemento se identifica por nombre, no por posición ordinal. Del mismo modo, considere el conjunto de tuplas (llamadas filas por SQL) que forman el cuerpo de la relación; un elemento se identifica por sus valores clave, no por su posición. Muchos programadores tienen dificultades para adaptarse a la idea de que, con respecto a las tablas de consulta, no hay un orden entre las filas. En otras palabras, una consulta en una tabla puede devolver filas en cualquier orden a menos que solicite explícitamente que los datos se ordenen de una manera específica, tal vez con fines de presentación.

Pero independientemente de la definición académica de un conjunto, incluso la implementación en el servidor SQL nunca ha garantizado ningún orden en los resultados. Esta publicación de blog de MSDN de 2005 realizada por un miembro del equipo optimizador de consultas indica que no debe confiar en absoluto en el orden de las operaciones intermedias.

Las reglas de reordenamiento pueden y violarán esta suposición (y lo hacen cuando sea inconveniente para usted, el desarrollador;). Tenga en cuenta que cuando reordenamos las operaciones para encontrar un plan más eficiente, podemos hacer que cambie el comportamiento de los pedidos para los nodos intermedios en el árbol. Si ha puesto una operación en el árbol que asume un orden intermedio particular, puede romperse.

Esta publicación de blog de Conor Cunningham (Arquitecto, motor central de SQL Server) " Sin cinturón de seguridad - Esperando orden sin ORDENAR POR " trata sobre SQL Server 2008. Tiene una tabla con 20k filas con un solo índice que parece devolver siempre filas en El mismo orden. Agregar un ORDER BY a la consulta ni siquiera cambia el plan de ejecución, por lo que no es como agregar uno hace que la consulta sea más costosa si el optimizador se da cuenta de que no la necesita. Pero una vez que agrega otras 20k filas a la tabla, de repente el plan de consulta cambia y ahora usa paralelismo y los resultados ya no están ordenados.

La parte difícil aquí es que no hay una forma razonable para que un usuario externo sepa cuándo cambiará un plan. El espacio de todos los planes es enorme y te duele pensarlo. El optimizador de SQL Server cambiará los planes, incluso para consultas simples, si cambian suficientes parámetros. Puede tener suerte y no tener un cambio de plan, o simplemente no puede pensar en este problema y agregar un ORDER BY.

Si necesitas más convincente solo lee estas publicaciones: