... ¿hay algún estándar o una convención sobre cómo se debe formatear el código SQL?
Estándar, no. Puede poner una declaración SQL completa en una línea en lo que respecta a un analizador SQL.
Convención, seguro que hay muchos. Depende de si está tratando de maximizar la capacidad de cambio o minimizar el espacio. He escrito formateadores SQL para ambos casos.
Acabo de usar combinaciones de caracteres particulares para decirme dónde romper la instrucción SQL.
Aquí hay un ejemplo de un formateador Java DB2 SQL que escribí. Otro programa Java generó el código Java. El SQL vino directamente de las SYSIBM
tablas.
protected void prepareIndex00Select(String codeFacl)
throws SQLException {
StringBuffer sb = new StringBuffer();
sb.append("SELECT CODE_FACL, SEQ_FACL, FILLER_TOF ");
sb.append(" , CODE_TOF, NAME_FACL, NAME_LENGTH ");
sb.append(" , CODE_FMB, ID_NCIC_ORI, NBR_PRINTER_PREFIX ");
sb.append(" , ID_PERSONNEL_OFC, COMPLEX_CODE ");
sb.append(" , PHS_CODE, DESIG_FACL_GRP, IND_DESIG_AUTH ");
sb.append(" , CODE_FACL_I_T, INTKEY_FACL, IND_CDM_SENTENCING ");
sb.append(" , MAL_FEM_IND, DEL_AFTER, IND_INMATES ");
sb.append(" , VALUE_SO_CPU_STD, VALUE_SO_CPU_DAY ");
sb.append(" , CODE_CAT, VALUE_DCN, XIDBKEY ");
sb.append(" , FACL_FK_REGN ");
sb.append(" FROM ");
sb.append(creator);
sb.append(".FACL ");
sb.append(" WHERE CODE_FACL = ? ");
if (additionalSQL != null) sb.append(additionalSQL);
psIndex00 = connection.prepareStatement(sb.toString());
psIndex00.setString(1, codeFacl);
} // End prepareIndex00Select method
Un poco tarde, solo me topé con esto, lo siento.
El formateador T-SQL de Poor Man es un formateador T-SQL de código abierto (biblioteca, complemento ssms, formateador de archivos de línea de comandos, etc.): la implementación es razonablemente modular y no debería ser muy difícil implementar un tokenizador y formateador MySQL para que coincida con los T-SQL (no lo he hecho principalmente porque no tengo experiencia ni uso MySQL en este momento, por lo que no es un buen uso de mi tiempo).
La biblioteca se implementa en C # (2.0) con una licencia AGPL, lo que significa que no puede redistribuirla comercialmente o exponerla como un servicio público sin publicar ninguna modificación, pero para el usuario interno no debería presentar problemas, ya sea personalizada o no.
Como ya respondió @Gilbert Le Blank, definitivamente no hay un estándar en el formato SQL, incluso los formateadores comerciales que existen, con las diferentes opciones que proporcionan, no convergen en los mismos valores predeterminados o incluso necesariamente admiten los mismos formatos de salida.
Con respecto a escribir su propia herramienta desde cero, le aconsejaría que no lo haga si necesita manejar una variedad de casos: al menos para T-SQL, manejo de lotes de múltiples declaraciones SQL con cláusulas CTE WITH, declaraciones MERGE, subconsultas y tablas derivadas, etc. resulta ser bastante difícil :)
En caso de que sea de alguna ayuda: http://www.architectshack.com/PoorMansTSqlFormatter.ashx
fuente