Lendro, 2011/6/9 Mozart Hasse <[email protected]>: >> O que você citou como índice/tabela "PRIMARIO" > Mozart, existe tabela primária? Creio que não.
Coloquei entre aspas exatamente para deixar claro que a terminologia usada é diferente da usual. Adequei o vocabulário da minha resposta ao da mensagem original, não aos livros que você escolheu, que não inseri na conversa. "Tabela primária" é outra forma de adequação de vocabulário já que, falando do SQL Server e do SyBase, todas as tabelas com chave primária são por padrão índices e não o que o PostgreSQL chama de tabelas. >> se o seu índice primário >E índice primário, existe? Pelo menos, não em SQL nem no modelo >relacional. Adequei o vocabulário da minha resposta ao da mensagem original, não aos livros que você escolheu, que não inseri na conversa. Se não quer fazer o mesmo ao menos cite suas referências e diga o que elas têm a ver com o assunto, já que a dúvida é sobre organização *física* dos dados. >> então ao percorrer sequencialmente as páginas da sua tabela ou índice > As páginas de um índice pode ser percorrido seqüencialmente? No SQL Server e no SyBase, sim. >> 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? Achou o create table no site da microsoft. Leia no treeview à sua esquerda a excelente documentação sobre organização física e vai ver que minhas observações seguem o que diz a documentação. > 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. Só se o SQL Server tivesse o otimizador do PostgreSQL. Uma organização diferente impõe técnicas de otimização diferentes, que chegam a excelentes resultados. > Não duvidando, só achei curioso e uma pesquisa superficial 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. Precisa ser muito menos superficial para chegar a conclusões condizentes com o banco de dados que tanto desconhece e adora criticar. SyBase também, diga-se de passagem. >> 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? Não. Foi você que leu superficialmente e "passou batido" por esta frase no mesmo link que indicou: ... PRIMARY KEY constraints default to CLUSTERED, and UNIQUE constraints default to NONCLUSTERED. > 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. Depende de como seu otimizador for construído e quais estatísticas você coletar. > O modelo relacional foi criado justamente para evitar esse tipo de > engessamento... ..., normalmente, essa é uma > otimização precoce, que acaba prejudicando todo o sistema para trazer > ganhos > marginais a apenas algumas consultas. Depende de como seu otimizador for construído e quais estatísticas você coletar. Acusar um BD de fazer otimização precoce sem conhecê-lo é uma crítica precoce. > 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. É por isso que no site que você leu superficialmente colocaram o artigo que explica que testes comparativos fizeram usando as duas abordagens e quais resultados os fizeram adotar este padrão. A expectativa era evitar críticas sem fundamento como essa. Pena que não tem como evitar a leitura superficial. A meu ver, eles pelo menos tentaram. A opinião deles sobre o que vem a ser o padrão de uso frequente de um banco de dados coincide com a minha vivência de uso de banco de dados, e exatamente por isso a diferença de desempenho que sempre observamos bateu com as conclusões deles. Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
