Perché SSMS sta inserendo nuove righe nella parte superiore di una tabella non nella parte inferiore?

Ogni volta che inserisco manualmente una riga in una tabella in SQL Server Management Studio 2008 (il database è SQL Server 2005) la mia nuova riga appare nella parte superiore dell'elenco anziché nella parte inferiore. Sto usando le colonne di identità e questo si traduce in cose del genere

id  row
42 first row
1 second row
2 third row

Quando le righe vengono recuperate e non ordinate esplicitamente. Ciò si traduce in un aspetto diverso quando vengono recuperate le righe per l'app Web e cambia ciò che TOP 1restituisce una query.

So di poterli order byfare, ma perché sta succedendo questo? La maggior parte dei miei dati viene inserita tramite un'applicazione Web, tutti gli inserimenti di questa applicazione generano un ordine First In First Out, ad es. L'ultimo inserimento è in fondo, quindi gli ID sono tutti in fila. C'è qualche impostazione nel server o Management Studio che causa questo ordinamento improprio?

sql-server ssms identity

— Ben Brocka
fonte

Come ho visto a volte, dipende dall'ordinamento del PK come vengono visualizzate le righe, se si seleziona una singola tabella. Se si effettuano alcuni join, può variare a seconda delle altre tabelle PK, FK e indici ...

— Guillermo Gutiérrez,

Fai attenzione anche alle scansioni di giostra .

— Michael Green,

Risposte:

Nel mondo SQL, l'ordine non è una proprietà intrinseca di un insieme di dati. Pertanto, non ricevi alcuna garanzia dal tuo RDBMS che i tuoi dati torneranno in un certo ordine - o anche in un ordine coerente - a meno che tu non interroghi i tuoi dati con unORDER BY clausola.

Da Craig Freedman :

La combinazione di TOP con ORDER BY aggiunge determinismo all'insieme di righe restituite. Senza ORDER BY, l'insieme di righe restituite dipende dal piano di query e può persino variare da un'esecuzione all'altra.

Utilizzare sempre ORDER BYse si prevede un ordine ben definito e coerente nel set di risultati. Non fare affidamento su come il database può archiviare le righe su disco (ad esempio tramite un indice cluster) per garantire un certo ordinamento dei dati nelle query.

— Nick Chammas
fonte

Solo per aumentare le altre risposte: una tabella è, per definizione, un insieme di righe non ordinate. Se non si specifica unORDER BY clausola, SQL Server è libero di restituire le righe nell'ordine che ritiene più efficiente. Questo spesso coinciderà semplicemente con l'ordine di inserimento, poiché la maggior parte delle tabelle ha un indice cluster su identità, datetime o altre colonne che aumentano monotonicamente, ma dovresti trattarlo esattamente come questo: una coincidenza. Può cambiare con nuovi dati, un aggiornamento delle statistiche, un flag di traccia, modifiche a maxdop, suggerimenti per le query, modifiche al join o dove clausole nella query, modifiche all'ottimizzatore a causa di un service pack / aggiornamento cumulativo / hotfix / upgrade, spostare il database su un altro server, ecc. ecc.

In altre parole, e so che conosci già la risposta, ma non si può affermare abbastanza:

Se vuoi fare affidamento sull'ordine di una query, aggiungi SEMPRE ORDER BY .

— Aaron Bertrand
fonte

Non avevo intenzione di dipendere dall'ordine, ma visivamente è un po 'fastidioso che i miei ultimi articoli inseriti siano improvvisamente in cima.

— Ben Brocka,

Suppongo che questo sia perché stai usando Open Table. In Management Studio 2008 questo comando è stato diviso in "Modifica le prime n righe" e "Seleziona le prime N righe": quando si sceglie quest'ultima, si è liberi di modificare la query risultante, ad esempio rimuovere la parte superiore e aggiungere un ordine.

— Aaron Bertrand

È Management Studio 2008, il server è il 2005, avrebbe dovuto essere più chiaro. Non sapevo che ci fosse un comando "open table", ho sempre usato gli selectstatments

— Ben Brocka

Ok, il punto è ancora valido, capisco che sia fastidioso che i dati tornino in un ordine che non ti aspetti, ma spero sia chiaro ora perché a SQL Server non importa davvero quale ordine ti aspetti a meno che tu non gli dica che ti interessa aggiungendo un ordine per clausola. :-)

— Aaron Bertrand

È perché la tabella è una tabella heap (molto probabilmente) e non è indicizzata. Rendi la colonna ID a PRIMARY KEYe IDENTITY. SQL Server archivia fisicamente i dati in base agli indici, ad esempio se l'id fosse un indice cluster (come una chiave primaria) i dati verrebbero archiviati fisicamente nell'ordine degli id e verrebbero restituiti in questo modo in una query anche senza una ORDER BYclausola. Altrimenti, l'ordinamento delle righe non è affatto importante per il database. Di conseguenza, avere un'applicazione dipende dall'ordine delle righe nel database (e anche dal fatto che le colonne siano in un certo ordine) non è una buona pratica. L'applicazione deve funzionare con qualsiasi chiave ci sia nel database per identificare le righe.

— Wil
fonte

Buono a sapersi. Sapevo che questo era un suggerimento per cambiare l'app da usare order by(è un'app ereditata con molte cattive pratiche) ma mi chiedevo esattamente perché sia successo.

— Ben Brocka,

Modificare la struttura della tabella in modo che SELECT *senza ORDER BY possa tornare nell'ordine "giusto" (ma non essere comunque garantito)?

— Aaron Bertrand

Su un semplice SELECT dalla tabella con un indice cluster tornerebbe nell'ordine dell'indice cluster. Non era chiaro come avrei dovuto essere che era un'illustrazione di quando i dati sono ordinati fisicamente da una determinata colonna, ma sicuramente non è scontato che in ogni query vengano restituiti correttamente. Colpa mia.

— Wil

Non importa quale sia l'indice cluster. SQL Server può comunque restituire l'ordine in base a qualche altro indice basato su un'ampia varietà di fattori. La creazione di una chiave primaria su alcune colonne NON FUNZIONA garantisce che le selezioni senza ordine tornino improvvisamente ordinate da quella colonna sempre. Potresti osservarlo per la maggior parte del tempo? Sicuro. Ma questo non è lo stesso di una garanzia. Non ho mai visto un orso polare sulla mia strada ma non esiste un campo di forza dell'orso polare che gli impedisca di accadere.

— Aaron Bertrand

Comunque il mio punto era che l'aggiunta di una ORDER BYclausola è una garanzia molto migliore (non importa molto meno dirompente) che apportare modifiche allo schema alla tabella e sperando che l'ordinamento sarà come ti aspetti, per sempre.

— Aaron Bertrand