2009-05-04 26 views
5

He trabajado con SQL durante varios años, principalmente MySQL/PhpMyAdmin, pero también Oracle/iSqlPlus y PL/SQL últimamente. He programado en PHP, Java, ActionScript y más. Me doy cuenta de que SQL no es un lenguaje de programación imperativo como los demás, pero ¿por qué los mensajes de error parecen mucho menos específicos en SQL? En otros entornos, me dirijo directamente a la raíz del problema. Más a menudo que no, MySQL me da errores como "error ALREDEDOR donde u.id = ..." e imprime toda la consulta. Esto es aún más difícil con los procedimientos almacenados, donde la depuración puede ser una pesadilla completa.¿Hay una mejor manera de depurar SQL?

¿Me falta una herramienta mágica/idioma/complemento/configuración que da mejores informes de errores o estamos atrapados con esto? Quiero un depurador o un lenguaje que me brinde la misma cantidad de control que Eclipse me da al establecer puntos de interrupción y recorrer el código. es posible?

+5

suena como una queja más de una pregunta adecuada. ¿Quieres un mejor depurador? ¿Quieres una mejor base de datos? ¿Qué es lo que quieres arreglar? ¿Dónde está el código que no funciona? –

+0

pregunta actualizada para responder S.Lott –

+0

Quizás sería bueno volver a formular su pregunta como "¿Hay alguna forma de obtener mejores (más detallados) mensajes de error de SQL". De lo contrario, puede enfrentar el cierre como "no es una pregunta". – lothar

Respuesta

5

Creo que la respuesta radica en el hecho de que SQL es un lenguaje basado en conjuntos con algunas cosas de procedimiento adjuntas. Dado que los diseñadores pensaban en términos basados ​​en conjuntos, no pensaron que el tipo ordinario de depuración que otros lenguajes tienen es importante. Sin embargo, creo que algo de esto está cambiando. Puede establecer puntos de interrupción en SQL Server 2008. No lo he usado realmente, ya que debe tener bases de datos SQL Server 2008 antes de que funcione y la mayoría de los nuestros todavía son SQL Server 2000. Pero está disponible y le permite avanzar cosas. Todavía tendrá problemas cuando su declaración seleccionada tenga 150 líneas y sepa que la sintaxis no es correcta, pero no puede indicar exactamente dónde, ya que es un solo comando.

Personalmente cuando estoy escribiendo un SP de procedimiento largo, construyo en un modo de prueba que incluye mostrándome los resultados de las cosas que hago, los valores de las variables clave en puntos específicos que me interesan y las impresiones que permiten Yo sé qué pasos se han completado y luego volviendo todo al terminar. De esa forma puedo ver lo que hubiera sucedido si se hubiera ejecutado de verdad, pero no he dañado ninguno de los datos en la base de datos si me equivoqué. Encuentro esto muy útil. Sin embargo, puede aumentar enormemente el tamaño de su proceso. Tengo una plantilla que uso que tiene la mayor parte de la estructura que necesito configurar, así que no me lleva demasiado tiempo hacerlo. Especialmente porque nunca agrego un inserto. actualizar o eliminar a un proceso sin antes probar la selección asociada para asegurar que tengo los registros que quiero.

1

Acepto su queja.

Crear un buen marco de trabajo y usarlo en exceso es lo que funciona mejor para mí.

Antes y después de cada transacción o pieza importante de la lógica, escribo el nombre del sproc, la marca de tiempo del paso y un recuento de filas (si corresponde) en mi tabla de registro. Encuentro que cuando hago esto, generalmente puedo reducir el problema en pocos minutos.

Agregue un parámetro de depuración al sproc (predeterminado en "N") y páselo a cualquier otro programa que llame para que pueda activar o desactivar el inicio de sesión.

3

Creo que la explicación es que los lenguajes "normales" tienen sentencias individuales mucho más pequeñas que SQL, por lo que la granularidad de sentencia única apunta a una parte mucho más pequeña del código en ellos que en SQL. Una sola instrucción SQL puede ser una página o más de longitud; en otros idiomas, generalmente es una sola línea.

No creo que sea imposible para los depuradores/IDEs identificar con mayor precisión los errores, pero sospecho que lo hace más difícil.

1

En cuanto a los puntos de interrupción y el paso a través del código, puede hacer esto con el servidor MS SQL (en mi opinión, es más fácil en 2005+ que en 2000).

Para los casos simples, la depuración temprana del desarrollo, los mensajes a veces crípticos suelen ser lo suficientemente buenos como para resolver el error - error de sintaxis, no puede hacer X con Y. Si estoy en una situación difícil, me ' Volveré a la "depuración de printf" en el texto de sproc porque es rápido y fácil. Después de un tiempo con su base de datos de su elección, los problemas simples se vuelven obsoletos y usted simplemente los toma con calma.

Sin embargo, una vez que se lanza el código, la complejidad de los problemas es demasiado alta. Me considero afortunado si puedo reproducirlos. Además, los lugares donde el desarrollador en mí querría un depurador del DBA en mí dice "de ninguna manera está poniendo un depurador allí".

0

Uso las siguientes tácticas.

Durante la escritura del procedimiento almacenado tienen una @procStep var cada vez que un nuevo paso lógico se ejecuta conjunto @procStep = "¿Qué ... que está pasando aquí";

el resto es here

Cuestiones relacionadas