Sybase ASE is actually a really decent RDBMS. What always amazes me is how they managed to completely screw things up to such an extent that they don't even get a mention when people do these sorts of articles and comparisons.

Agree with wicknicks that this is a great document.

Yeah, their blunders were always in the realm of business strategy, their technology has always been sound. For many years they styled themselves as a mobile apps company, while their database business languished. A real shame.

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...

Amazingly, integers are used for more than just primary keys. ("This is just an example. It could also be something... much better.")

Equally amazingly, generations of Sybase programmers and DBAs have managed, somehow. Perhaps it's you?

Yes. That would be the entire point of my comment.

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.

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.