Чому ЗАМОВЛЕННЯ НЕ належить до Перегляду?

Я розумію, що ви не можете мати ORDER BY погляд. (Принаймні, у SQL Server 2012, з яким я працюю)

Я також розумію, що "правильним" способом сортування подання є розміщення ORDER BYнавколо SELECTзаяви, яка запитує подання.

Але, будучи відносно новим у практичному SQL та звичаях поглядів, я хотів би зрозуміти, чому це робиться дизайном. Якщо я правильно слідкував за історією, це було колись можливо і було явно видалено з SQL Server 2008 і так далі (не цитуйте мене в точній версії).

Однак найкраща причина, з якої я можу придумати, чому Microsoft видалила цю функцію, - це те, що "вид - це несортований збір даних".

Я припускаю, що є вагома логічна причина, чому Погляд повинен бути несортованим. Чому перегляд не може бути просто згладженим набором даних? Чому конкретно без допису? Не здається, що важко придумати ситуації, коли (принаймні мені / ІМХО) здається відсортований погляд абсолютно інтуїтивно зрозумілим.

(Звичайно, індексовані погляди)

Вид не матеріалізований - дані не зберігаються, тож як їх можна сортувати? Вигляд схожий на збережену процедуру, яка просто містить SELECTпараметр без параметрів ... він не містить даних, він просто містить визначення запиту. Оскільки в різних посиланнях на представлення даних можуть знадобитися дані, відсортовані по-різному, спосіб, який ви це робите - як і вибір із таблиці, яка також є несортованою колекцією рядків, за визначенням - полягає у включенні порядку за зовнішнім запитом .

Також, щоб трохи ознайомитись з історією. Ви ніколи не могли поставити ORDER BYна вигляд, не включаючи також TOP. І в цьому випадку ORDER BYпродиктовано, до яких рядків були включені TOP, а не як вони будуть представлені. Так сталося, що в SQL Server 2000, якщо він TOPбув 100 PERCENTабо {some number >= number of rows in the table}, оптимізатор був досить спрощеним, і в кінцевому підсумку було створено план з таким видом, який відповідав би TOP/ORDER BY. Але така поведінка ніколи не була гарантована або задокументована - на неї покладалися лише на основі спостереження, що є поганою звичкою . Коли SQL Server 2005 вийшов, така поведінка почала «ламатися» через зміни в оптимізаторі, що призвели до різних планів і операторів, які використовуються - серед іншого,TOP / ORDER BYбуло б повністю ігноровано, якби це було TOP 100 PERCENT. Деякі клієнти скаржилися на це настільки голосно, що Microsoft видала прапор сліду, щоб відновити стару поведінку. Я не збираюся розповідати вам, що таке прапор, тому що я не хочу, щоб ви його використовували, і я хочу переконатися, що наміри правильні - якщо ви хочете передбачуваний порядок сортування, використовуйте ORDER BYдля зовнішнього запиту.

Підводячи підсумок і стільки ж, щоб уточнити зроблений вами пункт: Microsoft нічого не видалив . Вони зробили продукт краще, і як побічний ефект ця незадокументована, не гарантована поведінка стала менш надійною. В цілому, я думаю, що продукт краще для нього.

Якщо перегляд було дозволено сортувати, то яким має бути порядок результату тут?

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 

одна можливість полягає в тому, щоб уникнути суперечливих сортування - якщо представлення сортується за одним порядком, а вибір у цьому представленні сортується за іншим порядком (не знаючи про тип перегляду), може виникнути враження від продуктивності. Тож безпечніше залишати вимогу сортування користувачеві.

Ще одна причина: сортування пов'язане з вартістю продуктивності, тож навіщо штрафувати всіх користувачів із перегляду, коли лише деяким користувачам потрібен сорт.

ANSI SQL дозволяє виконувати ORDER BYзапит на самий зовнішній запит з різних причин. Одна з них - це те, що відбувається, коли підселектор / view / CTE приєднується до іншої таблиці, а зовнішній запит є ORDER BYсам.

Сервер SQL ніколи не підтримував його всередині представлення (якщо ви не обдурили його, використовуючи TOP 100 PERCENTякий, на мою думку, в основному викликає помилку).

Навіть якщо ви викликали помилку, результати ніколи не були надійними, а сортування не завжди виходило так, як ви очікували.

Дивіться цю публікацію в блозі команди оптимізатора запитів для повного технічного пояснення ТОП-100 відсотків ЗАМОВЛЕННЯ Вважається шкідливим.

Реалізація плану за замовчуванням для цього коду відбувається для сортування рядків як частини виконання операції TOP. Часто це означало, що результати повертаються в упорядкованому порядку, і це спонукало клієнтів вважати, що існує гарантія, що рядки будуть відсортовані. Це насправді не так. Якщо ви хочете, щоб рядки були повернуті користувачеві в упорядкованому порядку, вам потрібно скористатися ЗАМОВЛЕННЯМИ на найбільш віддалений блок запитів (на ANSI), щоб гарантувати вихідний порядок презентації.

Перегляди ведуть себе як таблиці, вміст яких визначається за результатами запиту.

Столи не мають порядку; вони просто мішки з рядами.

Тому перегляди також не мають порядку. Ви можете сортувати їх, вибравши рядки в певному ЗАМОВЛЕННІ.

Один з відповідей, який ще не наводиться, полягає в тому, що "порядок від" може перешкоджати натисканню предиката, що може сильно вплинути на продуктивність.

Прикладом може слугувати вигляд, який зводить великий набір даних у підсумок 10 рядків, що знаходиться вгорі 10 / Упорядковано:

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

У тому ж випадку із сильним присудком:

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

Це все ще займає стільки ж часу, тому що top / order by блокує предикат, який не запускався раніше в конвеєрі. Це може спричинити обробку непотрібних рядків, і план буде подібний до схеми без присудка.

Чи не має бути натискання перед замовленням, це дійсно вибір розробника і може змінити відповідь. Найчастіше поштовхом є логічний намір.

Використання "100-відсоткових" логічно дозволяє підштовхувати предикати, однак реалізація, на жаль, ігнорує "порядок" для цього випадку та перемагає наміри.

У реальних випадках використання хорошим компромісом було б, щоб двигун виконував "замовлення шляхом потягування". Це дозволить вказати "порядок на" в межах перегляду (з верхніми 100 відсотками або без верху), і це замовлення застосовується лише в тому випадку, якщо представлення вибрано безпосередньо, без явного порядку, без об'єднання, без сукупності, ні Перегляд ланцюжків тощо. Обидві випадки, перераховані вище, можуть підтримуватися цією простою моделлю.

ви можете створити подання, яке має порядок і зберігає порядок за запитом після:

виберіть топ 99,999999999999 відсотків * від ..... замовити за