I am thinking to write a converter that takes any oracle query and return Postgresql format of the query assuming table and columns are same.
what I do right now I do timely conversions so I have basic understanding about both and want some expert advice that is it easily possible or not?
Try to use "commercial" version of PostgreSQL - EnterpriseDB. It has an compatibility layer for Oracle.
If you're about to write the "convector" by your own: look at this github project: https://github.com/porcelli/plsql-parser. It's open-source parser for Oracle's SQL dialect. I have to warn you, even if you have AST for Oracle query it is still a lot of to do to convert AST into other SQL dialect. You will also need plenty of sample queries for testing. You can find some sample queries in this project's tests folder.
Also similar project was implemented for MySQL, but I can not find it's homepage now.
Part of the solution is to make available in PostgreSQL the functions available in Oracle. You can have a look at http://orafce.projects.pgfoundry.org/
"The goal of this project is to implemente some functions from Oracle database. Some date functions (next_day, last_day, trunc, round, ...), string functions and some modules (DBMS_ALERT, DBMS_OUTPUT, UTL_FILE, DBMS_PIPE, ...) are implemented now. Funcionality was verified on Oracle 10g and module is useful for production work."
Not possible for every query. They each have syntax and functionality that the other does not -- for example, the MODEL clause in Oracle, or PostgreSQL's special form of "SELECT DISTINCT ON".
Mostly, Oracle has functionality that PostgreSQL doesn't: http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_10002.htm
Related
I'm an experienced and happy jOOQ user.
I'm now working on a project that need to support multiple database engines (PostgreSQL, MySQL, Oracle at least).
We want something with the low level enough to have control on our queries. JPA/Hibernate are too high level for us.
I know jOOQ works with a metamodel, and that metamodel is generated from the database schema.
Is there any way to reuse the same jOOQ query definitions against different database engines (with the same schema, apart from engine specific differences) ?
Fine if we need to recompile the java classes if necessary. Compile time configuration is fine for us.
jOOQ has been designed for this. You need to do these things:
Have a Configuration with a SQLDialect ready depending on your JDBC connection. That's the easy part. That Configuration will automatically generate vendor specific SQL for all of your jOOQ queries. This can be done at runtime. No need for any compile time adaptations.
Make sure your tables / columns always use the same case, or turn off quoting in jOOQ's identifiers for case insensitive behaviour (depending on your MySQL configuration, that might not be enough, see the MySQL manual). You can then re-use the generated code from any of your database dialects on all the other dialects.
Make sure you only use jOOQ API that is annotated with #Support({ MYSQL, ORACLE, POSTGRES }). For example, DSL.toDate() cannot be used, because it doesn't support MySQL, but DSL.trunc() can be used, because all 3 target dialects are present.
We're increasingly also adding dialect specific information to the jOOQ manual, e.g. for the SHL() function:
-- ASE, HSQLDB, SQLDATAWAREHOUSE, SQLSERVER, SYBASE
(1 * CAST(power(2, 4) AS int))
-- AURORA_MYSQL, AURORA_POSTGRES, COCKROACHDB, CUBRID, MARIADB, MEMSQL, MYSQL, POSTGRES, SQLITE, VERTICA
(1 << 4)
-- DB2, INFORMIX
(1 * CAST(power(2, 4) AS integer))
-- FIREBIRD
bin_shl(1, 4)
-- H2
lshift(1, 4)
-- ORACLE
(1 * CAST(power(2, 4) AS number(10)))
-- TERADATA
shiftleft(1, 4)
-- ACCESS, DERBY, HANA, INGRES, REDSHIFT
/* UNSUPPORTED */
In order to ensure you're not accidentally writing a query that doesn't work on some dialect, you can:
Run integration tests e.g. using testcontainers on each target dialect
Use jOOQ's Checker Framework or ErrorProne integration for static code analysis. See also this blog post here.
As far as I can gather, there are commands which are native to SQL such as SELECT and DELETE, and there are commands which are part of MySQL but not native to SQL such as use and describe. Have I got that right?
In this link the difference seems to be implied by having the MySQL commands in lower case. Is there a resource which shows which commands belong to which group i.e. native SQL vs MySQL-specific?
SQL is a language standard. Defined by organisations like ISO, ANSI, DIN.
Each SQL database system provides SQL, but with different scope and syntax. So you can learn the standard, but than you have to look for the distinctions. Or you directly learn a syntax of a specific database system. It depends on your purposes.
By the way the commands themself are case-insensitive. So it is indifferent if you write "select" or "SELECT". I prefer lower case because it is easy to write. Other prefer upper case because it is easy to read. In many projects the convention is upper case.
Function Similar with to_char(datetime) that can be used both Oracle and MySQL?
I want to generate the ANSI SQL script to run both in oracle and in MySQL.
But, the generated ANSI SQL is working well. except the the error from to_char().
Is there any function that can be used in both db?
Date formatting abilities couldn't be more different. I think your best chance is to pick one of these:
Run an ALTER SESSION statement when you connect to Oracle to replicate the MySQL default date format and do all date formatting in your client app.
Write a custom wrapper function and use it in your queries. You have to fork function code and maintain two versions.
You still have DBMS-dependent code but it's isolated in your initialisation code (option #1) or your installation script (option #2).
Perhaps there's a third option: tweak your database abstraction library to detect column types in result sets and convert dates to custom objects (e.g., DateTime if you use PHP, Date if you use JavaScript, etc.).
Mysql and Oracle uses different syntax for converting date to string.
You should use different queries.
Is there any way to use T-SQL queries with MySQL database, like having a data connector that understand TSQL and can connect to MySQL?
Short answer, no.
By the time you've developed or found an interface that could translate T-SQL syntax into MySQL (correctly); you might as well have learnt the syntax required to write the MySQL you need.
It's not all that different to be honest; and it will broaden your knowledge and make you flexible for other types of database query languages.
I am working in a project where we are using SQL Server database currently. But recently a decision has been taken that the database will be changed to MySQL.
I am not using any stored procedures, views, triggers, user defined functions, etc. But I think even then some queries written for SQL Server will not be supported by MySQL.
Can anyone help: what are the things that I have to check (and change) so that all the queries will work properly for MySQL also?
Queries that I know without consulting the documentation that will not work:
(recursive) common table expressions
windowing functions
queries using the standard SQL string concatenation ||
UPDATEs with JOIN are different between the two systems
Date arithmetics: date_column + 1 behaves differently in SQL Server
Division by zero will produce an error
SQL Server will reject values that do not fit into a column (instead of silently truncating it, which MySQL does in the default installation)
DDL that will not work and might have an impact on performance and/or data quality
datetime columns where you need precision up to milliseconds
tables with check constraints
indexed views
triggers on views
table functions (select * from my_function(42);)
filtered indexes ("partial index")
function based indexes
There's always the option to take commercial support from MySQL AB for this problem. I'm pretty sure they've done enough MSSQL->MySQL migrations to know alot about that. If a price tag on the migration is not a problem.
Alternatively, you could try to run the MySQL Migration Toolkit over the data and look for meaningful error messages at the stuff it cannot migrate. MySQL Migration Toolkit is part of the MySQL GUI Tools.