Comparison of different SQL implementations(troels.arvin.dk)
troels.arvin.dk
Comparison of different SQL implementations
http://troels.arvin.dk/db/rdbms
10 comments
I thought I had seen it all until I used Sybase for the first time the other day. It complained about a syntax error near INTEGER in "CREATE TABLE foo (id INTEGER)". Turns out that INTEGER is not a type it understands.
...!
...!
But why would you even try to do that? You should be using an IDENTITY in that case.
http://manuals.sybase.com/onlinebooks/group-as/asg1250e/sqlu...
http://manuals.sybase.com/onlinebooks/group-as/asg1250e/sqlu...
Amazingly, integers are used for more than just primary keys. ("This is just an example. It could also be something... much better.")
Very good document. You might consider making this a wiki, So others can add to it?
Well, not really. Anyone who has ever ported a significant application between databases will tell you, the issues you encounter are little to do with SQL syntax, and everything to do with different locking strategies, the query optimizers making different decisions, etc.
I worked on one such project recently, it flew on SQL Server and ran like a dog on Oracle 10, until we used query rewriting and stored outlines to force behavior similar to the Oracle 7's rule-based optimizer. Or in SQL server, it's normal to create temporary tables on the fly - in Oracle it's normal to have a permanent temporary table structure and only the contents are local to your session and automatically deleted when you disconnect. I don't see any of that here.
I worked on one such project recently, it flew on SQL Server and ran like a dog on Oracle 10, until we used query rewriting and stored outlines to force behavior similar to the Oracle 7's rule-based optimizer. Or in SQL server, it's normal to create temporary tables on the fly - in Oracle it's normal to have a permanent temporary table structure and only the contents are local to your session and automatically deleted when you disconnect. I don't see any of that here.
What I was trying to say had nothing to do with the exact content of the document. The diversity in database implementations is so large that everyone has their two cents to contribute. A wiki provides such an environment.
I totally agree with your points on query optimization, and since you wrote it here, probably no one but me would ever read what you said. On his wiki, more people would read and perhaps refine your statement. As you'd notice, there's already a large incentive for one to go look there to know very specific details of a DB.
The documentation about databases out there are very high level and don't really give very specific details. This page seemed like an excellent start to that.
I totally agree with your points on query optimization, and since you wrote it here, probably no one but me would ever read what you said. On his wiki, more people would read and perhaps refine your statement. As you'd notice, there's already a large incentive for one to go look there to know very specific details of a DB.
The documentation about databases out there are very high level and don't really give very specific details. This page seemed like an excellent start to that.
Agree with wicknicks that this is a great document.