1

Am wondering if there are guidelines somewhere to write SQL code which is compatible in SQL Server, mySQL as well as postgreSQL. I am writing a program and the user has a choice of backend database. It will be really difficult for me to create separate queries for each and every db. I do not want to use an ORM or anything like that.

Thank you for your time.

1
  • My worry would be that you will lose out on a lot of optimisation gains (or optimisation opportunity!) if you dont cater for separate platforms. There will be things that MSSQL can do much faster in a stored procedure, than from dynamic SQL, for example - but I dont reckon MS Stored Procedure syntax is portable to much if anything else! Commented Dec 3, 2009 at 13:14

2 Answers 2

3

Well, the best path you can choose consist in adopting the SQL ISO Standard.

Postgres and MySQL are heavy supporters, but I don't know if you could say the same about SQL Server.

Anyway, i think that an ORM solution could be the best for you, because usually they abstract these differences very well.

But if you don't wanna use it you can always store your queries in different repositories, each one for a specific database and load them at runtime.

Sign up to request clarification or add additional context in comments.

1 Comment

Just a clarification for others: The ISO standard for SQL is not the "intersection" of the common elements in the various proprietary SQLs. It's what they should be, but not what they are. No DBMS implements all of ISO SQL, and every DBMS I've ever seen has at least some non-ISO extensions. If the situation were a Venn diagram in the space of all SQL features, with each SQL dialect/standard as a circle, no circle would fit entirely inside any other.
1

Follow SQL:2003 standards.

Do unit tests when porting code from one system to another.

Don't use functions without looking how they are implemented in the dbms and what they are accepting as parameters.

Stuff to watch out for: Some SUBSTRING functions are 0-based in one system and 1-based in another. DATEDIFF works differently too. Some dbms have microseconds for datetime data type some don't.

With that being said, writing truly portable SQL is a dream... but does it really matter to be truly portable? A skilled DBA should know the little differences and port SQL codes quickly.

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.