¿Por qué SSMS inserta nuevas filas en la parte superior de una tabla y no en la parte inferior?


14

Cada vez que inserto manualmente una fila en una tabla en SQL Server Management Studio 2008 (la base de datos es SQL Server 2005), mi nueva fila aparece en la parte SUPERIOR de la lista en lugar de en la parte inferior. Estoy usando columnas de identidad y esto da como resultado cosas como

id  row
42 first row
1 second row
2 third row

Cuando se obtienen filas y no se ordenan explícitamente. Esto da como resultado una apariencia diferente cuando se obtienen las filas para la aplicación web y cambia lo que TOP 1devuelve una consulta.

Sé que puedo order by, pero ¿por qué sucede esto? La mayoría de mis datos se insertan a través de una aplicación web, todas las inserciones de esta aplicación dan como resultado un pedido Primero en entrar, primero en salir, por ejemplo, la última inserción está en la parte inferior, por lo que los identificadores están todos en una fila. ¿Hay alguna configuración en el servidor o Management Studio que provoque este pedido incorrecto?


Como he visto a veces, depende de la ordenación de PK de cómo se muestran las filas, si selecciona una sola tabla. Si hace algunas uniones, puede cambiar dependiendo de las otras tablas PK, FK e índices ...
Guillermo Gutiérrez

Tenga en cuenta los escaneos de carrusel también.
Michael Green

Respuestas:


21

En el mundo SQL, el orden no es una propiedad inherente de un conjunto de datos. Por lo tanto, no obtiene garantías de su RDBMS de que sus datos volverán en un cierto orden, o incluso en un orden consistente, a menos que consulte sus datos con una ORDER BYcláusula.

De Craig Freedman :

La combinación de TOP con ORDER BY agrega determinismo al conjunto de filas devueltas. Sin ORDER BY, el conjunto de filas devueltas depende del plan de consulta e incluso puede variar de una ejecución a otra.

Úselo siempre ORDER BYsi espera un orden bien definido y consistente en su conjunto de resultados. Nunca confíe en cómo su base de datos puede almacenar las filas en el disco (por ejemplo, a través de un índice agrupado) para garantizar un cierto orden de datos en sus consultas.


13

Solo para aumentar las otras respuestas: una tabla es, por definición, un conjunto desordenado de filas. Si no especifica una ORDER BYcláusula, SQL Server puede devolver las filas en el orden que considere más eficiente. Esto suele coincidir con el orden de inserción, ya que la mayoría de las tablas tienen un índice agrupado de identidad, fecha y hora u otras columnas que aumentan monotónicamente, pero debe tratarlo exactamente así: una coincidencia. Puede cambiar con nuevos datos, una actualización de estadísticas, una marca de seguimiento, cambios en maxdop, sugerencias de consulta, cambios en las cláusulas de unión o dónde en la consulta, cambios en el optimizador debido a un paquete de servicio / actualización acumulativa / revisión / actualización, mover la base de datos a un servidor diferente, etc. etc.

En otras palabras, y sé que ya sabes la respuesta, pero no se puede decir lo suficiente:

Si desea confiar en el orden de una consulta, SIEMPRE agregue ORDER BY .


No planeaba depender del orden, pero visualmente es un poco molesto que mis últimos artículos insertados estén repentinamente en la parte superior.
Ben Brocka

Supongo que esto se debe a que estás usando Open Table. En Management Studio 2008, este comando se ha dividido en "Editar filas superiores n" y "Seleccionar filas superiores N": cuando elige esta última, puede editar la consulta resultante, por ejemplo, elimine la parte superior y agregue un orden por.
Aaron Bertrand

Es Management Studio 2008, el servidor es 2005, debería haber sido más claro. No sabía que había un comando de "mesa abierta", siempre he usado las selectdeclaraciones
Ben Brocka

44
Ok, el punto sigue en pie, entiendo que es molesto que los datos vuelvan en un orden que no esperas, pero espero que ahora esté claro por qué a SQL Server realmente no le importa el orden que esperas a menos que le digas que te importa agregando una orden por cláusula. :-)
Aaron Bertrand

1

Es porque la tabla es una tabla de montón (muy probablemente) y no está indexada. Hacer que el identificador de columna de una PRIMARY KEY, así como IDENTITY. SQL Server almacena físicamente los datos en función de los índices; por ejemplo, si la identificación fuera un índice agrupado (como una clave primaria), los datos se almacenarían físicamente en el orden de los identificadores y se devolverían de esa manera en una consulta incluso sin una ORDER BYcláusula De lo contrario, el orden de las filas no es importante para la base de datos. En consecuencia, tener una aplicación depende del orden de las filas en la base de datos (así como también dependiendo de que las columnas estén en cierto orden) no es una buena práctica. La aplicación necesita trabajar con cualquier clave que haya en la base de datos para identificar filas.


Bueno saber. Sabía que esto era una pista para cambiar la aplicación a usar order by(es una aplicación heredada con una gran cantidad de malas prácticas), pero me preguntaba exactamente por qué sucedió.
Ben Brocka

55
Cambiar la estructura de la mesa sólo para que SELECT *no ORDER BY podría volver a aparecer en el orden "correcto" (pero todavía no se puede garantizar)?
Aaron Bertrand

En un SELECT simple de la tabla con un índice agrupado, volvería en el orden del índice agrupado. No estaba tan claro como debería haber sido que era una ilustración de cuándo los datos son ordenados físicamente por una columna en particular, pero definitivamente no es un hecho que en cada consulta se devuelva correctamente. Mea culpa.
Wil

55
Realmente no importa cuál sea el índice agrupado. SQL Server aún puede devolver el pedido en función de algún otro índice en función de una amplia variedad de factores. Crear una clave principal en alguna columna NO GARANTIZA que las selecciones sin orden se vuelvan a ordenar de repente por esa columna siempre. ¿Podrías observar eso la mayor parte del tiempo? Seguro. Pero eso no es lo mismo que una garantía. Nunca he visto un oso polar en mi calle, pero no hay un campo de fuerza de oso polar que evite que suceda.
Aaron Bertrand

44
De todos modos, mi punto fue que agregar una ORDER BYcláusula es una garantía mucho mejor (no importa mucho menos perjudicial) que hacer cambios en el esquema de la tabla y esperar que el pedido sea como espera, para siempre.
Aaron Bertrand
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.