SQL is case-insenstive for all SQL functions (e.g. DATE(col_1) & date(col_1) are identical).
But the convention is to use upper case. So DATE(col_1) is the convention.
I have not come across a parser or linter that auto-capitalises. Is there a way to take a sql script, and auto capitalise it to convention?
Using an online sql formatter may cause information security violations depending on the company. If there is a risk, I recommend using the notepad++ replace all feature, but a little effort is needed.
Related
As indicated here
The following words are reserved for use in ODBC function calls. These words do not constrain the minimum SQL grammar; however, to ensure compatibility with drivers that support the core SQL grammar, applications should avoid using these keywords.
This list includes the word I'd like to use as a table name, Session, and seems to state pretty clearly that I should avoid its use.
But I don't have any current intention to use ODBC - I'll be using JDBC - and I don't really understand how bad this would be if, down the road, I changed my mind. Can anyone explain in more detail whether naming my table this way truly is a bad idea?
I'm looking more for personal experience than further technical references that don't convey the experience of dealing with the problems that might arise. This looks pretty unpleasant, but how often does it come up that one might switch from JDBC to ODBC realistically?
I am new to ANTLR & grammar writing. My requirement is to parse insert/update/delete SQL queries to get details like which table is being update/inserted/deleting a row, list of columns & their values etc. Yes there is a good documentation of ANTLR, but if anyone can help me with specific grammar for query parsing then it would be great help.
There are various SQL grammars on the Wiki: http://www.antlr.org/grammar/list
Beware though: they are contributed by ANTLR-users, chances are that they've not been properly tested and/or contain bugs.
But why generate an SQL parser yourself? It would probably be easier to use some exiting SQL parser. Just do a search on "SQL parser Java" (assuming you're working with Java), and you're bound to get dozens of hits.
Implementing a "decent" SQL parser is actually fairly hard. In SQL, one can write all kinds of complex statements (nested joins, ...), and people really do this, so you have to implement the "full" language. (I've seen SQL queries that cover tens of pages. Stupid, yes, but then you have to work with what you encounter).
I suggest checking out SQL2011 (the standard) as being rather comprehensive. However, that grammar may not be ANTLR friendly, so be prepared for a fair bit of work.
You also have to worry about database/vendor specific extensions to standard SQL. PL/SQL (just the SQL sublanguage part) contains lots of Oracle-specific extensions. If you are facing PL/SQL stored procedures, and you want to do that table/column tracing, you may have to do the procedural part of PL/SQL too, and that's also pretty big.
I'm looking for a SQL Implementation (and its Editor) that can be used for translating it to many other(s) SQL Languages.
For example, when i code in that SQL Language to script file(s), and then i translate to other(s) SQL Language script file(s) (for ex: MS SQL's , MySQL's , ...).
If you're sure to use only ANSI SQL to construct your scripts, you should be good to go.
I agree with #Justin Niessner: all SQL vendors pay attention to the SQL Standards, notably core SQL-92. To take SQL Server as an example, although they find Sybase legacy code is tricky to deprecate they are not afraid to do so and entirely new features (e.g. MERGE in MSSQL2008) tend to extend their Standard SQL equivalents, rather than reinventing the wheel.
For a product that has good Standards compliance, take a look at Mimer
Here at Mimer Information Technology, we pride ourselves on conforming
to the SQL standard and we play an active role in the Database
Languages standardization group which determines exactly what is SQL
standard.
Mimer also provide extremely useful SQL validators for SQL-92, SQL-99 and SQL:2003 respectively.
I've been researching the same thing a while ago. What I've found is that there is a project liquibase. It is aimed at change tracking but also converting between different DBMS. You can download source code and see different datatypes conversions across databases. Source at github browse for java files there, probably you'll find something helpful
If all you want are basic operations, these are fairly universal. For instance:
SELECT
INSERT
DELETE
UPDATE
FROM
WHERE
JOIN
...are all at the most basic level the same across implementations.
However, the more complicated your scripts get, the more difficult it becomes to make them "universal". Things like aggregation, subqueries, cursors, while loops, functions, indexes, constraints, temp tables, variables, string manipulation, window operations etc. are all pretty much database-specific.
Some of these do have "universal" equivalents but the more generic you make your code the worse it will perform.
Imagine an application which is supposed to work with different database vendors. As we all know the syntax for SQLs (especially DDL) is not portable. How do you deal with maintaing the SQL scripts?
Until now I see three options:
to store SQLs in format of one of the databases and have a tool which automatically converts from one syntax do another (do you know such tools?)
to store SQLs in some artificial language and a have a tool which is able to generate vendor-specific SQLs on demand (any recommendation here?)
to store SQLs in many database formats neglecting the redundancy (this is the worst one, isn't it?)
Do you recommend any of them? Do you have a better idea?
The development environment tries to follow the continuous integration principles, so automation is a key feature here.
Have a look at Liquibase (that's essentially your second item on the list)
http://www.liquibase.org
It's not perfect (e.g. it does not support check constraints) but it is quite useful
This video shows a solution using the Subsonic project http://subsonicproject.com/docs/Using_SimpleRepository and its data migration capabilities. The strategy is to use a general language and apply it to different databases.
Hope this is what you were looking for
Use some kind of ORM framework with schema generation capability.
I'm currently looking at some light-weight SQL abstraction modules. My workflow is such that i usually write SELECT queries manually, and INSERT/UPDATE queries via subs which take hashes.
Both of these modules seem perfect for my needs and i have a hard time deciding. SQL::Interp claims SQL::Abstract cannot provide full expressivity in SQL, but discusses no other differences.
Does it have any disadvantages? If so, which?
I can't speak to SQL::Interp, but I use SQL::Abstract and it's pretty good. In conjunction with DBIx::Connector and plain old DBI, I was able to totally eliminate the use of an ORM in my system with very little downside.
The only limitations I have run into is that it's not possible to write GROUP BY queries directly (although it's easy to do by simply appending to the generated query, and LIMIT queries are handled by the extension SQL::Abstract::Limit.
I used SQL::Abstract for a over a year, and then switched to SQL::Interp, which I've stuck with since.
SQL::Abstract had trouble with complex clauses. For the ones it could support, you would end up with a nest of "(" "[" and {" characters, which you were mentally translate back to meaning "AND", "OR" or actually parentheses.
SQL::Interp has no such limitations and uses no middle representation. Your SQL looks like SQL with bind variables where you want them. It works for complex queries as well as simple ones. I find SQL::Interp especially pleasant to use in combination with DBIx::Simple's built-in support for it. DBIx::Simple+SQL::Interp is a friendly and intuitive replacement for using raw DBI. I use the combination in a 100,000k+ LoC mod_perl web app.