Tabelas clusterizadas x não clusterizadas

Eu estava na mesma posição quando comecei minha carreira como SQL Server DBA, mas estudei principalmente ORACLE (10g) na minha universidade.. e esse negócio de OCA também...

Concordo com @KennethFisher que ambos os RDBMS são diferentes e compará-los é como comparar maçãs e laranjas.

Para responder à sua pergunta sobre - armazenar tabelas como árvores balanceadas ...

• Tanto o Oracle quanto o SQL Server suportam índices B-Tree que mantêm os dados classificados e permitem pesquisas, acesso sequencial, inserções e exclusões em tempo logarítmico.
• O B-Tree é bem otimizado para sistemas que leem e escrevem grandes blocos de dados. Observe que o SQL Server usa essa estrutura para índices não agrupados e o Oracle a usa como padrão para armazenar o local de armazenamento da tabela internamente.
• O Oracle tem um conceito de ROWID (ID de linha) e UROWID (ID de linha universal) onde os valores de chave e uma referência exclusiva ao local de armazenamento do registro estão contidos e isso representa o local físico no disco em que o registro está armazenado.

por exemplo , visão geral de referência dos tipos de dados ROWID e UROWID

SELECT ROWID, last_name FROM employees WHERE department_id = 20; 

ROWID              LAST_NAME 
------------------ ---------- 
AAAAaoAATAAABrXAAA BORTINS 
AAAAaoAATAAABrXAAE RUGGLES 
AAAAaoAATAAABrXAAG CHEN 
AAAAaoAATAAABrXAAN BLUMBERG 

Um rowid estendido tem um formato de quatro partes, OOOOOOFFFBBBBBBBRRR:

OOOOOO: O número do objeto de dados que identifica o segmento do banco de dados (AAAAao no exemplo). Objetos de esquema no mesmo segmento, como um cluster de tabelas, possuem o mesmo número de objeto de dados.

FFF: O número do arquivo de dados relativo ao espaço de tabela do arquivo de dados que contém a linha (arquivo AAT no exemplo).

BBBBBB: O bloco de dados que contém a linha (bloco AAABrX no exemplo). Os números dos blocos são relativos ao seu arquivo de dados, não ao tablespace. Portanto, duas linhas com números de blocos idênticos podem residir em dois arquivos de dados diferentes do mesmo espaço de tabela.

RRR: A linha no bloco.

• Portanto, os conceitos são completamente diferentes em RDBMS - ORACLE e SQL Server. Além disso, os PKs criados no Oracle nada mais são do que índices não clusterizados balanceados com ROWID para acesso rápido e, portanto, nenhum conceito de índices clusterizados ou não clusterizados.

Agora, isso fica mais interessante e diferente quando se trata de índices B+Tree :

• As estruturas B+Tree são semelhantes às estruturas B-Tree, mas os registros da tabela (dados reais) são armazenados nos nós de folha do Índice de chave primária, permitindo acesso rápido para correspondência exata ou pesquisas de varredura de intervalo no PK da tabela.

• O Oracle usa o que é chamado de IOT (Index Organized Tables) e o SQL Server usa o que é chamado de Clustered Indexes.

Vamos ver índices clusterizados e tabelas organizadas por índice (IOT)...:

Do documento Oracle ,

Uma tabela organizada por índice é uma tabela armazenada em uma variação de uma estrutura de índice de árvore B. Em uma tabela organizada por heap, as linhas são inseridas onde couberem. Em uma tabela organizada por índice, as linhas são armazenadas em um índice definido na chave primária da tabela. Cada entrada de índice na árvore B também armazena os valores da coluna não-chave. Assim, o índice são os dados e os dados são o índice. Os aplicativos manipulam tabelas organizadas por índice da mesma forma que tabelas organizadas por heap, usando instruções SQL.

Do documento do SQL Server ,

No SQL Server, os índices são organizados como árvores B. Cada página em uma árvore B de índice é chamada de nó de índice. O nó superior da árvore B é chamado de nó raiz. O nível inferior de nós no índice é chamado de nós folha. Quaisquer níveis de índice entre os nós raiz e folha são conhecidos coletivamente como níveis intermediários. Em um índice clusterizado, os nós folha contêm as páginas de dados da tabela subjacente. Os nós de nível raiz e intermediário contêm páginas de índice contendo linhas de índice. Cada linha de índice contém um valor de chave e um ponteiro para uma página de nível intermediário na árvore B ou uma linha de dados no nível folha do índice. As páginas em cada nível do índice são vinculadas em uma lista duplamente vinculada.

• As estatísticas para IOT incluem a dispersão física das linhas, enquanto o SQL Server não inclui a localização física das linhas nas estatísticas e, portanto, o índice clusterizado no SQL Server é melhor que um HEAP - os dados são classificados pela chave agrupada e boas estimativas são obtidas para os dados para ser pesquisado.

Finalmente algumas boas referências:

• Estatísticas em Oracle e SQL Server - por Jonathan Lewis e Grant Fritchey
• Oracle Heap Tables ou SQL Server Clustered Indexes? - por Jonathan Lewis e Grant Fritchey
• Tabelas Organizadas por Índice – o Básico – Excelente série!
• Corrigindo a fragmentação da pilha
• Internos e exclusões

Acrescentarei mais pontos quando me deparar que vale a pena mencionar ...

Na verdade, há uma resposta bastante simples. Oracle e RDBMS semelhantes são otimizados para usar heaps, enquanto MS SQL Server e similares são otimizados para usar índices clusterizados. Se você der uma olhada nas partes internas de cada sistema, descobrirá que seu design foi construído para lidar com o método escolhido. Portanto, neste caso particular, ambos os grupos de "Adeptos" estão corretos. No SQL Server as tabelas com índices clusterizados funcionam melhor, no Oracle os heaps funcionam melhor (em geral em ambos os casos). Não tenho certeza se qualquer abordagem é melhor ou pior em geral, é apenas uma questão de preferência dos designers do RDBMS. E com base no que vi das partes internas do MS SQL Server (ainda não estudei as partes internas da Oracle), não tenho certeza se você poderia escrever um RDBMS que funcionaria bem nos dois sentidos.