Comments on: SQL Server 4 http://jonathanlewis.wordpress.com/2010/06/28/sql-server-4/ Just another Oracle weblog Thu, 23 May 2013 12:47:17 +0000 hourly 1 http://wordpress.com/ By: Jonathan Lewis http://jonathanlewis.wordpress.com/2010/06/28/sql-server-4/#comment-36623 Wed, 30 Jun 2010 09:00:23 +0000 http://jonathanlewis.wordpress.com/?p=3991#comment-36623 Gary,

The locking issue is an interesting one. On an order processing system you’re less likely to have two people entering an order for the same customer at the same time – so minimising overlaps between customers reduces a block-level lock problem. conversely if the data is simply being stored (as the heap would do) in order of arrival then you’d be maximising block-level locking. I’ll have to mention that idea somewhere in the next couple of articles.

History does account for a lot of the strange beliefs in modern systems – but if you want to invoke history to explain the resistance to using index clustere you’d have to have a much better argument than “require a lot of planning”. (Technically it should require a lot of planning to pick the right clustered index in SQL Server – but I’m not sure it happens.)

]]> By: Gary http://jonathanlewis.wordpress.com/2010/06/28/sql-server-4/#comment-36604 Mon, 28 Jun 2010 22:47:36 +0000 http://jonathanlewis.wordpress.com/?p=3991#comment-36604 I came to Oracle from using Ingres, which also had ‘BTree’ structured tables as the preferred option. Looking back, I think one reason was the locking mechanism since, by clustering the records (eg for a customer), there was less impact when entire pages/blocks were locked.
I do remember that we had one monthly summary that did year-to-date figures, and it was quicker to re-organize the whole table with a different Btree key (and reorganise it back afterwards) than to do the maths with the ‘wrong’ structure.

Still, I’m sure SQL Server people would say Oracle dudes are married to heap structures because index-organized tables weren’t supported in Oracle for so long, and even now have to be on the primary key. Clustered tables always seemed to require a lot of planning.

]]>