Существуют ли канонические формы для запросов к базе данных?

Question

Скажите, что я хочу сделать "Оптимизированный генератор запросов". В основном оптимизатор SQL-запросов, который намного лучше, чем тот, который может быть помещен в SQL-сервер, исходя из временных и пространственных ограничений Он будет принимать запрос и статистику БД в качестве входных данных и генерировать запрос SQL с учетом целевой системы, который быстро оптимизируется до почти идеального плана.

Какой объем SQL необходимо будет поддерживать? Существует ли подмножество SQL, достаточно гибкое, чтобы легко описывать большинство полезных запросов, но достаточно меньше, чем полный SQL, чтобы его стоило урезать? Также есть ли лучший способ описать запросы, если вам не нужно придерживаться "близко к машине"?

Я не имею в виду программу, через которую вы будете обрабатывать существующий SQL, а скорее инструмент для создания нового SQL. Фактически не нужно принимать SQL в качестве входных данных, если язык ввода может описывать требования запроса.

Полагаю, другой формой вопроса был бы вопрос: есть ли какие-то части SQL, которые предназначены только для производительности и никогда не улучшают читабельность / понятность?

---

Как указано кем-то, что для этого потребуется «тонна знаний по конкретному продукту», и что (например, вложенные подзапросы или что-то еще, какие индексы следует использовать, что-то в этом роде) является именно тем инструментом предназначен для инкапсуляции, так что пользователю не нужно изучать эти знания.

---

примечание: Меня не интересует генерация планов фактических запросов, так как это задача СУБД , и она все равно не может быть выполнена из SQL. Меня интересует система, которая может автоматизировать работу по созданию хорошего SQL для данной СУБД на основе ввода, который не нужно настраивать для этой СУБД.

Answer 1

Я удивлен, услышав, что вы описываете SQL как "близко к машине". SQL сам по себе является декларативным, а не процедурным, и один из интересных аспектов реляционных баз данных - это свобода, которую должны внедрять разработчики свободы, поскольку сам SQL очень мало диктует, как должны выполняться запросы.

Я думаю, что для чистой утилиты было бы очень трудно улучшить SQL. Я не говорю, что это идеальный язык, но это лингва франка реляционных (и даже некоторых нереляционных) баз данных.

Answer 2

Брамха, я не уверен, знаете ли вы, что вы спрашиваете. Оптимизация SQL - это не просто проверка того, что компоненты запросов находятся в правильном порядке. Кажется, вы понимаете, что вам необходимо иметь глубокие знания об индексах, макетах страниц данных и т. Д. И т. Д., Но вам все равно придется просто переписывать предложения, если вы не получите соответствующие «зацепки» в запросе SQL Server. процессор. Потому что именно это и делает MS - она ​​по сути «компилирует» запросы на более глубоком, более фундаментальном уровне для оптимизации доступа к данным.

Answer 3

ммм ... есть (я думаю, что слишком ленив, чтобы гуглить) девять реляционных операторов (сканирование, переход, слияние хешей и т. Д.), Которые используются для построения плана выполнения запроса SQL. Выбор операторов основан на статистике использования таблиц целевой базы данных, доступных индексов и т. Д.

Похоже, вы пытаетесь воссоздать то, что уже делает планировщик запросов ...?

РЕДАКТИРОВАТЬ:

1. Я не думаю, что у большинства запросов есть столько вариантов их выполнения, а
2. Я не думаю, что вы могли бы что-то сделать с SQL, чтобы заставить механизм БД создать план выполнения «по-вашему», даже если вы нашли более оптимальное решение.
3. , если вы не планируете создавать свой собственный движок базы данных!

Я очень смущен этим вопросом; это похоже на изобретение колеса, но без фургона, на котором его можно установить!?

Answer 4

Это очень старый вопрос на данный момент, и я согласен с большинством других ответов, что, возможно, он немного ошибочен. Но в этом есть что-то. Вы читали «Настройка производительности SQL» Гулутзана и Пелзера (Addison-Wesley, 2003)? Он сравнивает количество СУБД и то, как эквивалентные, но по-разному сформулированные запросы влияют на время выполнения. Другими словами, какие идиосинкразии и ошибки существуют в оптимизаторах запросов.

Например, они обнаружили, что в большинстве систем предложение WHERE, такое как WHERE column1 = 'A' AND column2 = 'B', будет оцениваться слева направо, но справа налево в Oracle (при определенных условиях и в конкретной версии Oracle, которая была текущей когда они написали книгу). Поэтому наименее вероятное условие должно быть поставлено последним в Oracle, но первым в большинстве других систем.

Answer 5

Удачи - вы решили конкурировать с такими компаниями, как Microsoft и Oracle, которые живут или умирают благодаря тому, насколько хорошо их оптимизаторы запросов выполняют именно то, что вы предлагаете. Первый и основной способ сравнения одного продукта базы данных с другим - это тестирование производительности, при котором к каждому из них применяется одинаковая рабочая нагрузка, проводятся измерения времени, а победитель в большинстве случаев определяется скоростью выполнения.

Мир будет впечатлен, если вы сможете значительно лучше, чем издатель, использовать любой из этих тестов, используя их продукты. По крайней мере, у вас будет отличная возможность карьерного роста с любым из них, которые вы используете.

Answer 6

Собираетесь ли вы написать это для одного конкретного движка базы данных? Если нет, я подозреваю, что у вас будет довольно трудное время для этого. Оптимизация запросов к базе данных в значительной степени зависит от точных особенностей реализации механизма и внутренних компонентов, а также от таблиц, индексов, отношений первичного / внешнего ключа, типа и распределения данных и т. Д. И т. Д. Фактическая логика создания оптимизированного запроса будет Скорее всего, очень мало совпадений между различными движками базы данных. (В этом отношении, по крайней мере, для MySQL тип таблицы будет иметь огромное значение для оптимизации.) Каждый выпуск каждого поддерживаемого механизма БД также может иметь существенно разные характеристики - имейте в виду, что если вы генерируете SQL, то Вы должны быть в состоянии предсказать, как собственный оптимизатор / планировщик запросов будет обрабатывать сгенерированный вами SQL.

Дело в том, что оптимизация запросов слабо опирается на реляционную теорию и очень сильно зависит от подробных знаний о внутренностях БД и хранящихся данных. Даже если вам удастся извлечь метаданные БД, я подозреваю, что вам будет сложно составить план запроса лучше, чем сама БД - и если вы не получаете метаданные БД, ваша причина безнадежна ,

Answer 7

Шаблоны в «SQL-запросах для простых смертных» могут оказаться полезными, поскольку они работают в структурированном каноническом формате, начиная с описаний на английском языке.

Онлайн на Safari , если вы хотите быстро взглянуть.