Вопрос о теории SQL-запроса - отдельный оператор по сравнению с составными запросами
Когда я пишу SQL-запросы, я думаю часто, что "нет никакого способа сделать это с единым запросом". Когда это происходит, я часто обращаюсь к хранимым процедурам или составным табличным функциям, которые используют временные таблицы (одного вида или другого) и заканчивают тем просто, что комбинировали результаты и возвратили таблицу результата.
Я задаюсь вопросом, знает ли кто-либо, просто как теорию, должно ли быть возможно записать ЛЮБОЙ запрос, который возвращает единственный набор результатов как единый запрос (не несколько операторов). Очевидно, я игнорирую важные моменты, такие как удобочитаемость кода и пригодность для обслуживания, возможно, даже производительность запросов / эффективность. Это больше о теории - может это быть сделанным... и не волнуются, я, конечно, не планирую начать вынуждать меня записать, что запрос отдельного оператора, когда составной лучше удовлетворит моей цели во всех случаях, но это могло бы заставить меня думать дважды или немного дольше на том, существует ли жизнеспособный способ получить результат единого запроса.
Я предполагаю, что несколько параметров в порядке - я думаю о реляционной базе данных (такой как MS SQL) с таблицами, которые применяют общие лучшие методы (такие как все таблицы, имеющие первичный ключ и т.д).
Примечание: для завоевания 'Принятого Ответа' на этом, необходимо будет предоставить категорическое доказательство (ссылка на веб-материал или что-то подобное.)
5 ответов
По крайней мере, с недавней версией Oracle это абсолютно возможно. В ней есть "пункт модели", который делает sql turing завершенным. ( http://blog.schauderhaft.de/2009/06/18/building-a-turing-engine-in-oracle-sql-using-the-model-clause/ ). Конечно, все это с обычным ограничением, что на самом деле у нас нет неограниченного времени и памяти.
Для нормального sql диалекта без этих абдоминаций я не думаю, что это возможно.
Задача, которую я не вижу, как реализовать в "нормальном sql": Предположим, таблица с одним столбцом типа integer
Для каждой строки "возьмите значение в текущей строке и вернитесь на столько строк, получите это значение, вернитесь на столько строк и продолжайте до тех пор, пока не получите одно и то же значение дважды подряд и верните это значение в результате"
.] Я не могу это доказать, но думаю, что ответ - да, при условии, что дизайн вашей базы данных выполнен правильно. Обычно принуждение к написанию нескольких утверждений для получения определенного результата является признаком того, что Ваша схема может нуждаться в некоторых улучшениях.[
].] Думаю, это возможно. Я работал с очень сложными запросами, очень длинными запросами, и часто это можно сделать с одним запросом. Но в большинстве случаев, это сложнее, поэтому если вы делаете это с одним запросом, убедитесь, что вы внимательно комментируете свой запрос.[
][
]Я никогда не встречал ничего, что нельзя было бы сделать с одним запросом.[
].
Но иногда лучше сделать это в нескольких запросах.[
] Теоретически да, если вы используете функции или извилистый лабиринт ВЧАЙНЫХ ПРИЛОЖЕНИЙ или подзапросов, однако для удобочитаемости и производительности мы всегда заканчивали темпами таблиц и многоступенчатыми хранимыми процедурами. [
] [] Как заметил кто-то выше, это обычно признак того, что ваша структура данных начинает пахнуть; не то, чтобы [] плохо [], а то, что, возможно, пришло время денормализовать по причинам производительности (случается с лучшими из нас), или, возможно, поставить денормализованный слой запроса перед нормализованными "реальными" данными.[
].Я бы сказал "да", но не могу это доказать. Однако, мой основной мыслительный процесс:
Любая выборка должна быть операцией на основе множеств
Ваше предположение заключается в том, что вы имеете дело с математически правильными множествами (т.е. нормализованными правильно)
Теория множеств должна гарантировать, что это возможно
Другие мысли:
Многочисленные операторы SELECT часто загружают временные таблицы/переменные таблицы/переменные таблицы. Они могут быть получены или разделены в CTE.
Любая обработка RBAR (в хорошую или в плохую сторону) теперь обрабатывается с CROSS/OUTER APPLY на производные таблицы
UDF будут классифицированы как "обман" в этом контексте, как мне кажется, потому что это позволяет поместить SELECT в другой модуль, а не в единственный
Запись в вашей последовательности "до" DML запрещена: это изменяет состояние от SELECT к SELECT
Вы видели какой-то код в нашем магазине?
Правка, глоссарий
- RBAR = Row By Agonising Row
- CTE = Common Table Expression
- UDF = User Defined Function
Правка: APPLY: cheating?
SELECT
*
FROM
MyTable1 t1
CROSS APPLY
(
SELECT * FROM MyTable2 t2
WHERE t1.something = t2.something
) t2