Мы генерируем много процедурного SQL, и SQL Server убивает нас. Из-за некоторых проблем, задокументированных в других местах , мы в основном делаем SELECT TOP 2 ** 32 вместо TOP 100 PERCENT.
Примечание: мы должны использовать подзапросы.
Вот наш запрос:
SELECT * FROM (
SELECT [me].*, ROW_NUMBER() OVER( ORDER BY (SELECT(1)) )
AS rno__row__index FROM (
SELECT [me].[id], [me].[status] FROM (
SELECT TOP 4294967296 [me].[id], [me].[status] FROM
[PurchaseOrders] [me]
LEFT JOIN [POLineItems] [line_items]
ON [line_items].[id] = [me].[id]
WHERE ( [line_items].[part_id] = ? )
ORDER BY [me].[id] ASC
) [me]
) [me]
) rno_subq
WHERE rno__row__index BETWEEN 1 AND 25
Есть ли лучшие способы сделать это, что каждый может увидеть?
ОБНОВЛЕНИЕ : вот некоторые пояснения по всей проблеме подзапроса:
Ключевое слово моего вопроса - "процедурно". Мне нужна возможность надежно инкапсулировать наборы результатов, чтобы их можно было складывать вместе, как строительные блоки. Например, я хочу получить первые 10 компакт-дисков, упорядоченные по имени исполнителя, который их создал, а также получить соответствующего исполнителя для каждого компакт-диска. Что я делаю, так это собираю монолитный подвыбор, представляющий компакт-диски, упорядоченные по именам соединенных исполнителей, затем примените к нему ограничение, а затем присоедините вложенные вложенные элементы к таблице исполнителей и только затем выполните полученный запрос. Изоляция необходима, потому что код, который запрашивает упорядоченные компакт-диски, не связан и не учитывает код, выбирающий топ-10 компакт-дисков, который, в свою очередь, не связан и не замечает код, запрашивающий соответствующих исполнителей.
Теперь вы можете сказать, что я мог бы переместить внутренний ORDER BY в предложение OVER (), но затем я нарушил инкапсуляцию, так как мне пришлось бы ВЫБРАТЬ столбцы объединяемой таблицы, чтобы я мог заказать их позже. Дополнительной проблемой было бы объединение двух таблиц под одним псевдонимом; если бы в обеих таблицах были столбцы с одинаковыми именами, select me. * остановился бы здесь с неоднозначной ошибкой имени столбца.
Я готов немного пожертвовать производительностью оптимизатора, но 2 ** 32 кажется мне слишком взломанным. Поэтому я ищу золотую середину.