This is a nice idea, but my problem with most of these tools is that they work with pure SQL/JS/whatever files, which isn't always the case.

For example, if you use something like myBatis, you'll probably build the SQL dynamically, which could be stored in a mapper XML file: https://mybatis.org/mybatis-3/dynamic-sql.html

Not only that, but certain frameworks have you embedding SQL inside of the main application code, when you're not using a DSL like HQL: https://www.tutorialspoint.com/hibernate/hibernate_query_lan... and https://www.tutorialspoint.com/hibernate/hibernate_native_sq...

Furthermore, there seems to be this odd separation between "regular SQL" and "procedural SQL" in some DBVSes, such as in Oracle - there you might have to use "DECLARE ... BEGIN ... END;" in certain contexts, or maybe "EXECUTE IMMEDIATE". Then again, Oracle isn't among the supported dialects, which is perfectly understandable, because of both how the DBVS is positioned, as well as because of how large an undertaking supporting it would be: https://docs.sqlfluff.com/en/stable/dialects.html

In short, the only passable tools that i've found for checking SQL are those that are integrated within the IDE, or using a specialized IDE with any plugins for specific technologies, like JetBrains DataGrip (commercial project): https://www.jetbrains.com/datagrip/

But then you run into the issue of code style preferences: some companies have style guides where you have to use reserved words in uppercase with the dev created content in lowercase, like:

  SELECT some_column, another_column, yet_another_column AS one_more 
  FROM some_table 
  WHERE some_column > SYSDATE

while certain tools (like SQL Developer) are more than happy to use autocomplete which doesn't work well with that:

  SELECT (start typing in "som") FROM some_table ...
  Oracle will autocomplete to: SOME_COLUMN

And then you run into people's personal preferences, for example some format the columns that they want to select like this:

  SELECT
      some_column
    , another_column
    , yet_another_column
  FROM ...

which makes sense when you want to edit single lines, but could have been avoided by the SQL standard allowing dangling commas, like some other languages do, for example:

  SELECT
    some_column,
    another_column,
    yet_another_column,
  FROM ...

but as it currently stands, that's not possible and the other way of formatting code also tends to break linters. And since the actual formatting of SQL doesn't matter as much as it would in Python, we end up with every IDE and other tool having their own preferences.

I guess the lesson here is to avoid complexity as much as possible and just settle on whatever works.