Существуют ли канонические формы для запросов к базе данных?
Скажем, я хочу сделать "Оптимизированный генератор запросов". В основном оптимизатор SQL-запросов, который намного лучше, чем тот, который может быть помещен в SQL-сервер в зависимости от времени / пространства. Он будет принимать запрос и статистику БД в качестве входных данных и генерировать запрос SQL с учетом целевой системы, который быстро оптимизируется до почти идеального плана.
Какой объем SQL нужно будет поддерживать? Существует ли подмножество SQL, достаточно гибкое, чтобы легко описывать большинство полезных запросов, но достаточно меньше, чем полный SQL, чтобы его стоило урезать? Также есть ли лучший способ описать запросы, если вам не нужно придерживаться "близко к машине"?
Я не имею в виду программу, через которую вы будете обрабатывать существующий SQL, а скорее инструмент для создания нового SQL. Фактически не нужно принимать SQL в качестве входных данных, если язык ввода может описать требования запроса.
Я предполагаю, что другой формой вопроса будет: есть ли какие-либо части SQL, которые предназначены только для производительности и никогда не улучшают читабельность / понятность?
Как указано кем-то, что для этого потребуется "тонны знаний по конкретному продукту" и что (например, вложенные подзапросы против чего бы то ни было, какие индексы следует использовать, что-то в этом роде) - это именно то, что инструмент будет предназначен для инкапсуляции так что пользователю не нужно изучать эти знания.
примечание: я не заинтересован в создании реальных планов запросов, так как это работа СУБД и все равно не может быть выполнена из SQL. Меня интересует система, которая может автоматизировать работу по созданию хорошего SQL для данной СУБД на основе ввода, который не нужно настраивать для этой СУБД.
7 ответов
Я удивлен, когда вы описываете SQL как "близко к машине". SQL сам по себе является декларативным, а не процедурным, и один из интересных аспектов реляционных баз данных - это свобода, которую должны внедрять разработчики свободы, поскольку сам SQL очень мало диктует, как должны выполняться запросы.
Я думаю, что для чистой пользы было бы очень трудно улучшить SQL. Я не говорю, что это идеальный язык, но это лингва франка реляционных (и даже некоторых нереляционных) баз данных.
Брамха, я не уверен, что ты знаешь, о чем просишь. Оптимизация SQL - это не просто проверка того, что компоненты запросов находятся в правильном порядке. Кажется, вы понимаете, что вам нужно иметь глубокие знания об индексах, разметке страниц данных и т. Д. И т. Д., Но вам все равно придется просто переписывать предложения запроса, если вы не получите соответствующие "крючки" в запросе SQL Server. процессор. Потому что именно это и делает MS - она по сути "компилирует" запросы на более глубоком, более фундаментальном уровне для оптимизации доступа к данным.
Хм... есть (я думаю, слишком ленив, чтобы гуглить это) девять реляционных операторов (сканирование, переход, слияние хешей и т. д.), которые используются для построения плана выполнения SQL-запроса. Выбор операторов основан на статистике использования таблиц целевой базы данных, доступных индексов и др.
Похоже, вы пытаетесь воссоздать то, что планировщик запросов уже делает...?
РЕДАКТИРОВАТЬ:
- Я не думаю, что большинство запросов имеют так много вариантов того, как они могут быть выполнены, и
- Я не думаю, что вы могли бы что-то сделать с SQL, чтобы заставить механизм БД создать план выполнения "по-вашему", даже если вы нашли более оптимальное решение.
- если вы не планируете создавать свой собственный движок базы данных!
Я очень смущен этим вопросом; это похоже на изобретение колеса, но без универсала для его установки!?
Сейчас это очень старый вопрос, и я согласен с большинством других ответов, что, возможно, он немного ошибочен. Но в этом есть что-то. Вы читали "Настройка производительности SQL" Гулутзана и Пелзера (Addison-Wesley, 2003)? Он сравнивает количество СУБД и то, как эквивалентные, но по-разному сформулированные запросы влияют на время выполнения. Другими словами, какие идиосинкразии и ошибки существуют в оптимизаторах запросов.
Например, они обнаружили, что в большинстве систем предложение WHERE, такое как WHERE column1 = 'A' AND column2 = 'B' будет оцениваться слева направо, но справа налево в Oracle (при определенных условиях и в конкретной версии Oracle, действовавшей на момент написания книги). Поэтому наименее вероятное условие должно быть поставлено последним в Oracle, но первым в большинстве других систем.
Вы намерены написать это для одного конкретного движка базы данных? Если нет, я подозреваю, что у вас будет довольно трудное время для этого. Оптимизация запросов к базе данных в значительной степени зависит от точных особенностей реализации механизма и внутренних компонентов, а также от таблиц, индексов, отношений первичного / внешнего ключа, типа и распределения данных и т. Д. И т. Д. Фактическая логика создания оптимизированного запроса будет Скорее всего, очень мало совпадений между различными движками базы данных. (В этом отношении, по крайней мере, для MySQL тип таблицы будет иметь огромное значение для оптимизации.) Каждый выпуск каждого поддерживаемого механизма БД также может иметь существенно разные характеристики - имейте в виду, что если вы генерируете SQL, то Вы должны быть в состоянии предсказать, как собственный оптимизатор / планировщик запросов будет обрабатывать сгенерированный вами SQL.
Дело в том, что оптимизация запросов слабо опирается на реляционную теорию и очень сильно зависит от подробных знаний о внутренностях БД и хранящихся данных. Даже если вы сможете извлечь метаданные БД, я подозреваю, что вам будет сложно составить план запроса лучше, чем сама БД - и если вы не получаете метаданные БД, то ваша причина безнадежна,
Удачи - вы решили конкурировать с такими компаниями, как Microsoft и Oracle, которые живут или умирают от того, насколько хорошо их оптимизаторы запросов выполняют именно то, что вы предлагаете. Первый и основной способ сравнения одного продукта базы данных с другим - это тестирование производительности, при котором к каждому из них применяется одинаковая рабочая нагрузка, проводятся измерения времени, а победитель в большинстве случаев определяется скоростью выполнения.
Мир будет впечатлен, если вы сможете добиться значительно большего успеха, чем издатель, по любым из этих тестов, используя их продукты. По крайней мере, у вас будет отличная возможность сделать карьеру, независимо от того, какой из них вы используете.
Вы можете найти шаблоны в "SQL-запросах для простых смертных" полезными, поскольку они работают в структурированном каноническом формате, начиная с английских описаний.
Онлайн в Safari, если вы хотите быстро взглянуть.