Mengapa SSMS memasukkan baris baru di bagian atas tabel bukan bagian bawah?


14

Setiap kali saya secara manual memasukkan baris ke tabel di SQL Server Management Studio 2008 (database SQL Server 2005) baris baru saya muncul di TOP daftar daripada di bagian bawah. Saya menggunakan kolom identitas dan ini menghasilkan hal-hal seperti

id  row
42 first row
1 second row
2 third row

Ketika baris diambil dan tidak dipesan secara eksplisit. Ini menghasilkan tampilan yang berbeda ketika baris diambil untuk aplikasi web dan mengubah apa yang TOP 1dikembalikan permintaan.

Saya tahu saya bisa order by, tetapi mengapa ini terjadi? Sebagian besar data saya dimasukkan melalui aplikasi web, semua sisipan dari aplikasi ini menghasilkan pemesanan First In First Out, mis. Insert terbaru ada di bagian bawah, sehingga id semua dalam satu baris. Apakah ada pengaturan di server atau Management Studio yang menyebabkan pemesanan yang tidak tepat ini?


Seperti yang saya lihat kadang-kadang, itu tergantung pada pemesanan PK bagaimana baris ditampilkan, jika Anda memilih satu tabel. Jika Anda membuat beberapa bergabung, itu dapat berubah tergantung pada tabel lain PK, FK dan indeks ...
Guillermo Gutiérrez

Waspadai scan komidi putar juga.
Michael Green

Jawaban:


21

Di dunia SQL, pesanan bukan properti yang melekat dari set data. Dengan demikian, Anda tidak mendapatkan jaminan dari RDBMS Anda bahwa data Anda akan kembali dalam urutan tertentu - atau bahkan dalam urutan yang konsisten - kecuali jika Anda meminta data Anda dengan ORDER BYklausa.

Dari Craig Freedman :

Menggabungkan TOP dengan ORDER BY menambahkan determinisme ke rangkaian baris yang dikembalikan. Tanpa ORDER BY, rangkaian baris yang dikembalikan tergantung pada rencana kueri dan bahkan dapat bervariasi dari eksekusi ke eksekusi.

Selalu gunakan ORDER BYjika Anda mengharapkan pesanan yang didefinisikan dengan baik dan konsisten dalam rangkaian hasil Anda. Jangan pernah mengandalkan bagaimana database Anda dapat menyimpan baris pada disk (misalnya melalui indeks berkerumun) untuk menjamin pemesanan data tertentu dalam permintaan Anda.


13

Hanya untuk menambah jawaban lainnya: sebuah tabel, menurut definisi, adalah satu set baris yang tidak teratur. Jika Anda tidak menentukan ORDER BYklausa, SQL Server bebas untuk mengembalikan baris dalam urutan apa pun yang dianggap paling efisien. Ini sering terjadi bersamaan dengan urutan penyisipan, karena sebagian besar tabel memiliki indeks berkerumun pada identitas, datetime atau kolom yang meningkat secara monoton, tetapi Anda harus memperlakukannya persis seperti itu: kebetulan. Itu dapat berubah dengan data baru, pembaruan statistik, tanda jejak, perubahan ke maxdop, petunjuk kueri, perubahan pada bergabung atau di mana klausa dalam kueri, perubahan ke pengoptimal karena paket layanan / pembaruan kumulatif / perbaikan terbaru / peningkatan, memindahkan database ke server lain, dll. dll.

Dengan kata lain, dan saya tahu Anda sudah tahu jawabannya, tetapi tidak cukup untuk menyatakan:

Jika Anda ingin mengandalkan urutan kueri, SELALU tambahkan ORDER BY .


Saya tidak berencana untuk bergantung pada pesanan, tetapi secara visual agak menjengkelkan bahwa barang-barang saya yang dimasukkan terakhir tiba-tiba di atas.
Ben Brocka

Saya kira ini karena Anda menggunakan Open Table. Di Management Studio 2008 perintah ini telah dipecah menjadi "Edit Top n Rows" dan "Select Top N rows" - ketika Anda memilih yang terakhir, Anda bebas untuk mengedit kueri yang dihasilkan, mis. Hapus bagian atas dan tambahkan pesanan dengan.
Aaron Bertrand

Itu Manajemen studio 2008, server adalah 2005, seharusnya lebih jelas. Saya tidak tahu ada perintah "open table", saya selalu menggunakan selectstatments
Ben Brocka

4
Ok, well point masih berdiri, saya mengerti itu menjengkelkan bahwa data kembali dalam urutan yang tidak Anda harapkan, tapi saya harap itu jelas sekarang mengapa SQL Server tidak benar-benar peduli urutan apa yang Anda harapkan kecuali jika Anda memberi tahu bahwa Anda peduli dengan menambahkan pesanan demi klausa. :-)
Aaron Bertrand

1

Itu karena tabel adalah tabel tumpukan (kemungkinan besar) dan tidak diindeks. Membuat ID kolom PRIMARY KEYserta IDENTITY. SQL Server secara fisik menyimpan data berdasarkan indeks - misalnya, jika id adalah indeks berkerumun (seperti kunci utama) data akan secara fisik disimpan dalam urutan id dan akan dikembalikan seperti itu dalam permintaan bahkan tanpa sebuah ORDER BYklausa. Kalau tidak, pemesanan baris tidak penting untuk database sama sekali. Akibatnya, memiliki aplikasi bergantung pada urutan baris dalam basis data (dan juga tergantung pada kolom dalam urutan tertentu) bukan praktik yang baik. Aplikasi perlu bekerja dengan kunci apa pun yang ada dalam database untuk mengidentifikasi baris.


Senang mendengarnya. Saya tahu ini adalah petunjuk untuk mengubah aplikasi yang akan digunakan order by(ini adalah aplikasi bawaan dengan banyak praktik buruk) tetapi saya bertanya-tanya mengapa hal itu terjadi.
Ben Brocka

5
Ubah struktur tabel hanya agar SELECT *tanpa ORDER BY mungkin kembali dalam urutan "benar" (tetapi masih belum dijamin)?
Aaron Bertrand

Pada SELECT sederhana dari tabel dengan indeks berkerumun akan kembali dalam urutan indeks berkerumun. Tidak sejelas yang seharusnya saya bahwa itu adalah ilustrasi tentang kapan data dipesan oleh kolom tertentu secara fisik, tetapi jelas bukan mengingat bahwa dalam setiap permintaan itu akan dikembalikan dengan benar. MEA Culpa.
Wil

5
Tidak masalah apa indeks berkerumun itu. SQL Server masih dapat mengembalikan urutan berdasarkan beberapa indeks lain berdasarkan berbagai faktor. Membuat kunci utama pada beberapa kolom JANGAN menjamin bahwa memilih tanpa urutan akan tiba-tiba kembali dipesan oleh kolom itu selalu. Mungkinkah Anda mengamati itu sebagian besar waktu? Tentu. Tapi itu tidak sama dengan jaminan. Saya belum pernah melihat beruang kutub di jalan saya, tetapi tidak ada lapangan gaya beruang kutub yang mencegahnya terjadi.
Aaron Bertrand

4
Pokoknya poin saya adalah menambahkan ORDER BYklausa adalah jaminan yang jauh lebih baik (apalagi mengganggu) daripada membuat skema perubahan ke tabel dan berharap bahwa pemesanan akan seperti yang Anda harapkan, selamanya.
Aaron Bertrand
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.