Почему нет приличного парсера sql?

Question

В настоящее время я делаю некоторый анализ SQL оракула и часто сталкиваюсь с действительным оператором SQL, который не может быть должным образом проанализирован различными синтаксическими анализаторами SQL.Либо они не в состоянии анализировать его, либо генерируется их абстрактное синтаксическое дерево, так или иначе.Кажется, что единственный синтаксический анализатор, который действительно может обрабатывать Oracle OQL, - это их собственный, который не является общедоступным и не может быть получен как отдельный анализатор.

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

Как вы думаете, что является основными причинами, которые затрудняют реализацию парсеров sql вообще или парсеров Oracle оракула в частности?

Бест, Уилл

Answer 1

Хорошие парсеры сложно написать. Это начинается с генератора кода для кода синтаксического анализатора (который обычно использует некоторый (E) BNF-подобный синтаксис, который имеет свои собственные ограничения).

Обработка ошибок в парсерах - это отдельная тема для исследования. Речь идет не только об обнаружении ошибок, но и о предоставлении полезной информации о том, что может быть не так и как ее устранить. Некоторые парсеры даже не предоставляют информацию о местоположении («произошла ошибка в строке / столбце»).

Далее у вас есть SQL, что означает «Язык структурированных запросов», а не « Стандартный Язык запросов». Существует стандарт SQL, даже несколько, но вы не найдете ни одной базы данных, которая реализует какую-либо из них.

Oracle неохотно предлагает VARCHAR, но вам лучше использовать VARCHAR2. Некоторые базы данных предлагают рекурсивные / древовидные запросы. Все они используют для этого свой особый синтаксис. Присоединение определено довольно четко в стандарте (join, left join, ...), но зачем беспокоиться, если вы можете использовать +?

Кроме того, для каждой версии базы данных в грамматику добавляются новые функции.

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

Одним из решений было бы, если бы все поставщики баз данных опубликовали файлы грамматики. Но это драгоценности короны (IP). Поэтому вы должны быть рады, что вы можете использовать их без необходимости платить лицензионный сбор за анализируемый символ * количество процессоров.

Answer 2

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

Это верно для SQL, C, C ++ ... я знаю только те языки, на которых люди пытаются действительно трудно соответствовать стандарту - это Ада, и даже она существует на нескольких диалектах.(Посмотрите, что принимают браузеры!).

Таким образом, вы не можете ожидать, что стандартный синтаксический анализатор SQL проанализирует PLSQL.Вы действительно должны иметь анализатор PLSQL.И их сложно построить, так как документация скудна, у Oracle нет причин ее исправлять, и, конечно, у нее нет мотивации помогать сборщику грамматики.

В моей компании (Semantic Designs) есть синтаксический анализатор PLSQL, который довольно хорошо покрывает 10g (документация Oracle плохая ... мы продолжаем находить варианты из справочных документов) и делает большую часть 11g.Мы пробежали миллионы строк кода PLSQL.

Answer 3

Metadata.

SELECT identifier_1.identifier_2 ИЗ таблицы

может означать, что identifier_1 является схемой или пакетом, а identifier_2 может быть функцией или синонимом функции.

Существует целое значениепричин, по которым оператор может быть правильным, но не может быть понят без метаданных об объектах базы данных.Учитывая эти ограничения, существует предел того, как далеко может идти анализ.

Если синтаксический анализатор может обработать 80% вашего кода, а 15% не может быть обработан без метаданных, есть уменьшение отдачи при растяжении синтаксического анализатора, чтобы справиться с отсутствующими "5%".

Answer 4

Они делают это неправильно?:) ... Очевидно, это можно сделать, поскольку парсеры в ядрах баз данных работают нормально;) ... Это может быть связано с несколькими факторами.Диалект, возможно, не был хорошо документирован, или могли быть недавние изменения в диалекте, не реализованные в рассматриваемом синтаксическом анализаторе.

Answer 5

Если вы посмотрите на ссылку Oracle SQL: http://docs.oracle.com/cd/B28359_01/server.111/b28286/toc.htm

вы будете знать, насколько сложно создать синтаксический анализатор SQL, полностью поддерживающий весь синтаксис Oracle SQL, это почти невозможно.

Даже в приведенной выше документации не задокументирован весь синтаксис, который можно использовать для создания анализатора Oracle SQL.

Для каждой версии базы данных постоянно добавляется новый синтаксис.

Я думаю, что SQL Parser, такой как general sql parser , который охватывает наиболее важный синтаксис SQL различных основных баз данных, возможно, на выбор.