4 ms·

Lack of support for row level locking was a problem. I recall having to work around that by padding records with extra columns to ensure only one row would fit

Lack of support for row level locking was a problem. I recall having to work around that by padding records with extra columns to ensure only one row would fit on a page. But I'd say more generally the bigger issue was in their overall approach to concurrency. Oracle's optimistic currency control mechanism (where readers don't wait for writers) worked better in practice than Sybase's early lock-based concurrency control (where they did). I recall Philip Greenspun dedicated a substantial portion of his late 90's database-backed website book to that topic.

CaptainZapp 14y ago
That, again, very much depends on your application design. Sybase SQLServer (now ASE) was designed from the ground up as an OLTP database. It required that you keep your write and update transactions really short. I've seen - and worked on projects - that had an amazing throughput. They where, however, designed from the ground up, to perform well on the underlying database. Where Sybase' concurrency turned to dreadful, was when you ran chained transactions on isolation level 3. All I can say is: don't try this at home, folks. Also, Oracle's locking mechanism didn't come free. I remember (and my Oracle knowledge is really minimal) the dreadful, overflowing rollback log, whoms sizing was a science of its own. I'm not saying one is better then the other, but it points out quite nicely the impact of desing decisions. And how they always come with a price.
- drunkenhacker 14y ago
  > They where, however, designed from the ground up, to perform well on the underlying database. Unlike this sentence.
- ams6110 14y ago
  To really perform well, applications do need to be written with the underlying database in mind. The popularity of ORM-based data access layers has duped a lot of folks into believing that you don't have to think too much about the database.

CaptainZapp 14y ago

That, again, very much depends on your application design. Sybase SQLServer (now ASE) was designed from the ground up as an OLTP database. It required that you keep your write and update transactions really short. I've seen - and worked on projects - that had an amazing throughput. They where, however, designed from the ground up, to perform well on the underlying database. Where Sybase' concurrency turned to dreadful, was when you ran chained transactions on isolation level 3. All I can say is: don't try this at home, folks. Also, Oracle's locking mechanism didn't come free. I remember (and my Oracle knowledge is really minimal) the dreadful, overflowing rollback log, whoms sizing was a science of its own. I'm not saying one is better then the other, but it points out quite nicely the impact of desing decisions. And how they always come with a price.

drunkenhacker 14y ago
> They where, however, designed from the ground up, to perform well on the underlying database. Unlike this sentence.
ams6110 14y ago
To really perform well, applications do need to be written with the underlying database in mind. The popularity of ORM-based data access layers has duped a lot of folks into believing that you don't have to think too much about the database.