2011/6/9 Mozart Hasse <mozart.ha...@usa.net>: > > O que você citou como índice/tabela "PRIMARIO"
Mozart, existe tabela primária? Creio que não. > se o seu índice primário E índice primário, existe? Pelo menos, não em SQL nem no modelo relacional. > então ao percorrer sequencialmente as páginas da sua tabela ou índice As páginas de um índice pode ser percorrido seqüencialmente? > só é possível escolher um critério para chamar de "primário", enquanto que > todos os outros índices farão referência aos dados existentes na tabela, às > vezes usando este critério de ordenação. Mozart, creio que a confusão sua e da Izana vem da confusão entre os níveis lógico e físico, respectivamente entre chave e índice. Chave primária é um conceito do SQL, já abandonado há muito tempo no modelo relacional, e que não corresponde a índices. > O PostgreSQL, por padrão, armazena os registros conforme sua conveniência, > sem nenhum critério de ordenação definido. Já o SQL Server, por exemplo, > ordena por padrão todos os dados de uma tabela por sua chave primária. Cada > abordagem tem suas vantagens e desvantagens. Referência? Parece curiosamente ineficiente, já que impõe trabalho adicional na escrita, manutenção, e só beneficia leituras seqüenciais, um caso relativamente raro na prática. Não duvidando, só achei curioso… e uma pesquisa superficial <http://msdn.microsoft.com/en-us/library/ms174979(v=SQL.110).aspx> parece indicar que o comportamento do MS SQL Server é exatamente o mesmo do PostgreSQL, e aliás de todos os outros SGBDs SQL de que já ouvi falar. > No SQL Server é possível definir qual o critério de ordenação criando o > índice com a opção CLUSTERED, padrão para chaves primárias. http://msdn.microsoft.com/en-us/library/ms174979(v=SQL.110).aspx diz o contrário. Mudou na versão em desenvolvimento? > Manter os dados ordenados fisicamente dentro da tabela ajuda imensamente na > otimização de consultas De algumas consultas, não todas, nem necessariamente das mais relevantes. Sempre se pode reorganizar uma tabela física para refletir um novo padrão de uso que passou a ser mais relevante que o original mas, na prática, costuma levar a limitar o uso: consultas que não se conformem à organização da tabela tenderão a ser menos usadas. O modelo relacional foi criado justamente para evitar esse tipo de engessamento. Não significa que o DBA não possa organizar tabelas que realmente possam se beneficiar disso; é só que, normalmente, essa é uma otimização precoce, que acaba prejudicando todo o sistema para trazer ganhos marginais a apenas algumas consultas. A ’melhor prática’, no caso, é criar todas as tabelas desordenadas, como é o padrão, e ordenar apenas aquelas que, no uso real, provem precisar disso. Simplesmente afirmar que ‘manter os dados ordenados fisicamente… ajuda’, sem relativizar, é incorreto. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
