Live data from Hacker News

Comparison of different SQL implementations

troels.arvin.dk

1–10 of 11 posts

Re: Comparison of different SQL implementations

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

Re: Comparison of different SQL implementations

#5

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.

Re: Comparison of different SQL implementations

#6
post #3

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

Re: Comparison of different SQL implementations

#7

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.

Re: Comparison of different SQL implementations

#8
post #6
post #3

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

Re: Comparison of different SQL implementations

#9
post #8
post #6

Earlier quoted context omitted.

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?

Re: Comparison of different SQL implementations

#10
post #9
post #8

Earlier quoted context omitted.

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.
Post reply on HN