SİPARİŞ BY neden bir görünüme ait değil?

Ben anlıyorum bunu olamaz ORDER BY bir görünümde. (En azından SQL Server 2012'de çalışıyorum)

Ayrıca, bir görünümü sıralamanın "doğru" yolunun, görünümü sorgulayan ifadenin ORDER BYetrafına yerleştirilmesi olduğunu da anlıyorum SELECT.

Ancak pratik SQL ve görüşlerin kullanımında nispeten yeni olan bunun neden böyle bir tasarım tarafından yapıldığını anlamak istiyorum . Geçmişi doğru takip ettiysem, bu bir zamanlar mümkün olmuştu ve açıkça SQL Server 2008 ve benzeri bir şekilde kaldırılmıştı.

Ancak, Microsoft'un bu özelliği kaldırmasının nedenini anlayabilmemin en iyi nedeni "görünüm sıralanmamış bir veri toplama" olmasıdır.

Bir Görünümün neden sıralanmaması gerektiğine dair iyi ve mantıklı bir neden olduğunu varsayıyorum. Neden bir görünüm düzleştirilmiş bir veri toplama olamıyor? Neden özellikle un -sorted? (En azından bana / IMHO'ya) tasnif edilmiş bir görüşe sahip olmak için tamamen sezgisel göründüğü durumlarla karşılaşmak zor görünmüyor.

(İndekslenmiş görünümler bir yana, elbette.)

Bir görünüm gerçekleşmedi - veriler saklanmadı, nasıl sıralanabilir? Bir görünüm, sadece SELECTparametresiz olan bir saklı yordam gibidir ... veri içermez, sadece sorgunun tanımını tutar. Görünüme farklı referanslar, farklı şekillerde sıralanan verilere ihtiyaç duyabileceğinden, bunu yapma şekliniz - tıpkı sıralanmamış bir sıra koleksiyonu olan bir tablodan seçim yapmak gibi - tanımı gereği - sıraya göre dış sorguya dahil etmektir. .

Ayrıca tarihe biraz içgörü vermek. Sen olabilir asla koymak ORDER BYda dahil olmadan, bir görünümde TOP. Ve bu durumda, nasıl sunulacağını değil, ORDER BYhangi satırların eklendiğini belirledi TOP. Sadece eğer öyleyse 2000, SQL Server, bu oldu TOPoldu 100 PERCENTya {some number >= number of rows in the table}, iyileştirici oldukça basit ve o eşleşen bir çeşit bir plan üretme sona erdi TOP/ORDER BY. Ancak bu davranış hiçbir zaman garanti edilemedi veya belgelenmedi - kötü bir alışkanlık olan gözlemlere dayanıyordu . SQL Server 2005 ortaya çıktığında, bu davranış farklı optimizasyondaki farklı planların ve operatörlerin kullanılmasına yol açan değişiklikler nedeniyle “kırılmaya” başladı - diğerTOP / ORDER BYolsaydı tamamen göz ardı edilirdi TOP 100 PERCENT. Bazı müşteriler bu konuda yüksek sesle şikayet ettiler, çünkü Microsoft eski davranışını eski haline getirmek için bir izleme bayrağı yayınladı. Bayrağın ne olduğunu söyleyemem çünkü onu kullanmanızı istemiyorum ve amacın doğru olduğundan emin olmak istiyorum - tahmin edilebilir bir sıralama düzeni istiyorsanız ORDER BY, dış sorguda kullanın.

Özetlemek ve yaptığınız bir noktayı netleştirmek için: Microsoft hiçbir şeyi kaldırmadı . Ürünü daha iyi hale getirdiler ve bu belgelenmemiş bir yan etki olarak, garanti edilmeyen davranışlar daha az güvenilir hale geldi. Genel olarak, ürünün bunun için daha iyi olduğunu düşünüyorum.

Bir görünümün sıralanmasına izin verildiyse, buradaki sonucun sırası ne olmalıdır?

CREATE VIEW dbo.V1
AS
  SELECT number
  FROM   SomeTable
  ORDER  BY number ASC

GO

CREATE VIEW dbo.V2
AS
  SELECT number
  FROM   SomeTable
  ORDER  BY number DESC

GO

SELECT *
FROM   dbo.V1
       JOIN dbo.V2
         ON V1.number = V2.number 

Bir olasılık, çakışan sıralamalardan kaçınmaktır - görünüm bir sıraya göre sıralanıyorsa ve bu görünümdeki seçim başka bir sıraya göre sıralanıyorsa (görünüm sıralamasından habersiz), performans çarpması olabilir. Bu nedenle, sıralama gereksinimini kullanıcıya bırakmak daha güvenlidir.

Başka bir sebeple, sıralama bir performans maliyeti ile birlikte gelir, o nedenle neden yalnızca bazı kullanıcılar bu listeye gereksinim duyduğunda tüm görüşlerini cezalandırıyor?

ANSI SQL ORDER BY, en dış sorguya çeşitli nedenlerden ötürü izin verir; bunlardan biri, bir alt seçim / görünüm / CTE başka bir tabloya katıldığında ve dış sorgu bir ORDER BYkendisine sahip olduğunda olur.

SQL server bir görünüm içinde hiçbir zaman desteklemedi ( TOP 100 PERCENTbence çoğunlukla bir hatayı tetikleyen hangisini kullanıyorsanız ).

Hatayı tetikleseniz bile, sonuçlar hiç güvenilir olmamıştır ve sıralama her zaman beklediğiniz şekilde gerçekleşmemiştir.

Teknik bir açıklama için Query Optimizer ekibinin bu blog gönderisine bakın. TOP 100 Yüzde SİPARİŞ BY Zararlı.

Bu kod için varsayılan plan uygulaması, satırları TOP işlemini gerçekleştirmenin bir parçası olarak sıralar. Genelde bu, sonuçların sıralama düzeninde döndürüldüğü anlamına geliyordu ve bu da müşterilerin satırların sıralandığına dair bir garanti olduğuna inanmasına neden oldu. Bu aslında durum böyle değil. Satırların kullanıcıya sıralı sırada döndürülmesini istiyorsanız, çıktı sunum sırasını garanti etmek için en dıştaki sorgu bloğunda (ANSI'ye göre) bir SİPARİŞ BY kullanmanız gerekir.

Görünümler, içeriği bir sorgunun sonuçlarına göre belirlenen tablolara benzer şekilde davranır.

Tabloların sırası yoktur; Onlar sadece sıra çantalar.

Bu nedenle, görünümlerin de sırası yoktur. Bununla birlikte, belirli bir SİPARİŞ satırındaki satırları seçerek bunları sıralayabilirsiniz.

Henüz verilmeyen bir cevap, "sipariş verme" işleminin performansı büyük ölçüde etkileyebilecek zorla itmeye engel olabileceğidir.

Bir örnek, büyük bir veri kümesini, ilk 10 / Sıralı olan 10 satırlık özete ekleyen bir görünüme sahip:

select * from TopOrderedView; -- Ordered 10 line summary in 5s

Güçlü bir yüklem ile aynı durumda:

select * from TopOrderedView where <condition>; -- Ordered 2 line summary in still 5s

Hala aynı miktarda zaman alıyor çünkü en üstteki / emir, yüklemin boru hattında daha önce çalışmasını engelliyor. Bu, gereksiz satırların işlenmesine neden olabilir ve plan bir tahminde bulunmaksızın benzer olacaktır.

İtme işleminin sipariş öncesinde gerçekleşmesi gerekip gerekmediği gerçekten bir geliştirici seçimidir ve cevabı değiştirebilir. Çoğu zaman itme mantıksal niyettir.

"En iyi yüzde 100" kullanımı mantıklı bir şekilde tahmin edilmesine izin verir, ancak uygulama ne yazık ki bu durum için "sırayı" dikkate almaz ve amacını yitirir.

Gerçek kullanım durumlarında, motorun "çekerek sipariş vermesi" için iyi bir uzlaşma olur. Bu, görünümde bir "sıranın" belirtilmesine izin verir (en üst yüzde 100'le veya üstü olmayan) ve bu sıra yalnızca görünüm doğrudan, açık bir sıra olmadan, birleştirme, toplanma, öbek seçilmediği takdirde kullanılır. zincirleme vs.'yi görüntüleyin. Yukarıda listelenen her iki durum da bu basit model tarafından desteklenebilir.

aşağıdakilere göre sıralanıp siparişi koruyan bir görünüm oluşturabilirsiniz:

üst 99.999999999999 yüzde * 'yi seçin .....