¿Por qué no hay un analizador SQL decente?

Question

Actualmente estoy haciendo un análisis de Oracle sql y, a menudo, encuentro una declaración de SQL válida que no puede ser analizada correctamente por varios analizadores SQL. O fallan al analizarlo, o su árbol de sintaxis abstracta generado de alguna manera está en mal estado. Parece que el único analizador que realmente puede manejar Oracle sql es el propio que no está disponible públicamente y no puede obtenerse como un analizador independiente.

Soy consciente de que existen diferentes gramáticas SQL y que no sea posible cumplir con todas. Pero incluso los analizadores que dicen ser analizadores de Oracle SQL no tienen éxito en todos los casos.

¿Cuáles cree que son las principales razones que hacen que sea difícil implementar analizadores sql en general o analizadores sql de Oracle en particular?

mejor, Will

Answer 1

Los analizadores buenos son difíciles de escribir. Eso comienza con el generador de código para el código del analizador (que usualmente come una sintaxis similar a la de (E) BNF que tiene sus propias limitaciones).

El manejo de errores en analizadores es un tema de investigación propio. No se trata solo de detectar errores sino también de proporcionar información útil sobre lo que podría estar mal y cómo resolverlo. Algunos analizadores ni siquiera ofrecen información de ubicación ("el error ocurrió en la línea/columna").

A continuación, tiene SQL que significa "Lenguaje de consulta estructurado", no "Estándar Idioma de consulta". Hay un estándar SQL, incluso varios, pero no encontrará una única base de datos que implemente alguno de ellos.

Oracle a regañadientes ofrece VARCHAR pero es mejor que use VARCHAR2. Algunas bases de datos ofrecen consultas recursivas/tipo arbol. Todos ellos usan su propia sintaxis especial para esto. La unión se define bastante claramente en el estándar (join, left join, ...) pero ¿para qué molestarse si puede usar +?

Además de eso, para cada versión de base de datos, se agregan nuevas características a la gramática.

Si bien podría escribir un analizador que pueda leer los casos estándar, es casi imposible escribir un analizador que admita todas las funciones que ofrecen todas las bases de datos en todo el mundo. Y ni siquiera estoy hablando de los errores que puedes encontrar en estos analizadores.

Una solución sería si todos los proveedores de bases de datos publicaran los archivos de gramática. Pero estas son joyas de la corona (IP). Por lo tanto, debe estar contento de poder usar sin tener que pagar una tarifa de licencia por caracter analizado * cantidad de CPU.

Answer 2

Lo hacen mal? :) ... Obviamente se puede hacer ya que los analizadores sintácticos en los motores de la base de datos funcionan bien;) ... Probablemente se deba a varios factores. Es posible que el dialecto no esté bien documentado o que haya habido cambios recientes en el dialecto que no se hayan implementado en el analizador en cuestión.

Answer 3

Cuando un fabricante afirma que admite un idioma X, significa "algo así como el estándar X" pero no el estándar. Los fabricantes por razones históricas implementan el lenguaje X antes de que el estándar fuera como estándar, por lo que comienzan con el pie izquierdo; tratando de hacer que su versión coincida con, el estándar generalmente rompe su gran base de código de usuario; y siempre quieren agregar sus propios objetos para encerrar a sus usuarios.

Esto es válido para SQL, C, C++ ...los únicos idiomas que conozco donde la gente intenta realmente difícil de igualar el estándar es Ada, e incluso viene en múltiples dialectos. (¡Mira lo que aceptan los navegadores!).

Por lo tanto, no puede esperar que un analizador genérico genérico de SQL analice PLSQL. Realmente tienes que tener un analizador PLSQL. Y estos son difíciles de construir ya que la documentación es deficiente, Oracle no tiene motivos para arreglarlo, y ciertamente no tiene motivación para ayudar al generador de gramática.

Mi empresa (Diseños semánticos) tiene un PLSQL parser que cubre 10g bastante bien (la documentación de Oracle es pobre ... seguimos encontrando variaciones de los documentos de referencia) y hace la mayor parte de 11g. Lo hemos ejecutado a través de millones de líneas de código PLSQL.

Answer 4

Metadatos.

SELECT FROM tabla identifier_1.identifier_2

podría significar identifier_1 es un esquema o un paquete, y identifier_2 podría ser una función o un sinónimo de una función.

Hay una gran cantidad de razones por las cuales una declaración puede ser correcta pero no se puede entender sin los metadatos sobre los objetos de la base de datos. Teniendo en cuenta esas limitaciones, hay un límite de hasta dónde puede llegar un análisis.

Si un analizador puede calcular el 80% de su código y el 15% no se puede resolver sin los metadatos, se reducen los retornos al estirar el analizador para hacer frente al "5%" que falta.

Answer 5

Si se echa un vistazo a Oracle consulta de SQL: http://docs.oracle.com/cd/B28359_01/server.111/b28286/toc.htm

usted sabrá lo difícil que es crear un Analizador de SQL que es totalmente compatible con todos sintaxis SQL de Oracle, es casi imposible.

Incluso la documentación enumerada anteriormente no ha documentado toda la sintaxis con precisión que se puede utilizar para crear un analizador de Oracle SQL.

Para cada versión de base de datos, se agregará constantemente nueva sintaxis.

Creo que un analizador SQL como general sql parser que cubre la sintaxis SQL más importante de varias bases de datos importantes, puede ser una opción.