2011/6/11 Mozart Hasse <[email protected]>:
>
> 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.
Senti uma espetada aí. Não sei de outra teoria relacional que seja
relevante para alguma outra linguagem SQL; mais do que isso, nunca vi
nenhum livro que usasse esse vocabulário, nem no contexto de SGBDs nem
em nenhum outro contexto… realmente, não deu para (eu) entender.
> "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.
Vixe, agora é que boiei mesmo. O que seria uma tabela primária,
então? Em que as tabelas do PostgreSQL diferem das do Sybase ou MS
SQL Server? Como assim uma tabela com chave primária *é* (em vez de
_ter_) índice?
Vocabulário é importante, nem que seja para gente menos esperta, como
eu, conseguir funcionar…
> a dúvida é sobre organização *física* dos dados.
Bom, mas aí é que está — no modelo físico, que sentido faz falar em
(índice, não chave nem tabela) primário ou secundário? Mesmo no caso
de uma tabela organizada por alguma chave, essa chave não
necessariamente seria a primária, e poderia até (teoricamente)
dispensar um índice, não?
>> As páginas de um índice pode ser percorrido seqüencialmente?
>
> No SQL Server e no SyBase, sim.
Em alguns casos, imagino, não em todos?
> 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.
Não consegui, o que achei parece contradizer tuas afirmações…
A árvore, como a vejo, não tem nada sobre organização física. Também
procurei por ‘physical organization’ com o Bing embutido acima dela, e
nada… deve ser leseira minha.
> 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.
Me parece um argumento partindo dos resultados… continua faltando a
explicação que, implicitamente, pedi acima: como preservar eficiência
no caso geral quando se otimiza para um caso específico.
> 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.
Adoro criticar? Quisera eu não houvesse criticar. Aliás, quisera
nunca tê-lo conhecido. Pelo menos, conheço um pouco, tanto o MS
quanto o Sybase SQL Server,
> 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.
Dica, que peguei do CS Lewis, bem mais esperto que eu: nunca tente
adivinhar o que passava na cabeça doutro autor. A taxa de erro é
quase igual a 100%.
No caso, se passei batido por algo foi tua frase original, que entendi
se referir à ordem das tabelas, como o contexto parece indicar.
Relendo, vejo meu erro, reforçado ainda pela citação parcial do
parágrafo (?) original.
Então, apagando e voltando de onde errei:
> A definição de quando a tabela/índice será ordenado ou não depende de banco
> para banco. 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.
Até aqui tudo bem, falas apenas de índices de chaves primárias.
> Já no PostgreSQL, existe o comando CLUSTER para a mesma finalidade, que
> sempre deve ser explicitado quando desejado. Importante salientar que no
> PostgreSQL uma tabela com a opção CLUSTER só fica ordenada imediatamente
> após a sua reorganização ("recluster").
Na verdade, o problema que percebi está na relação deste parágrafo com
o anterior. Pareces comparar índices no MS SQL Server com tabelas no
PostgreSQL, o que obviamente não faz sentido; portanto, não sei se
entendi o que querias dizer. O que posso dizer é que, enquanto no MS
SQL Server o índice pode ser classificado, e (aparentemente) não a
tabela, no PostgreSQL a tabela pode ser agrupada
<http://doc.postgresqlfr.org/9.1/sql-cluster.html>, e não o índice
<http://doc.postgresqlfr.org/9.1/sql-createindex.html>.
> Depende de como seu otimizador for construído e quais estatísticas você
> coletar.
Na verdade, só se o planejador (otimizador não é um nome correto) for
ruim, ou as estatísticas deficientes. E isso só reforçaria o problema
que aponto.
Veja, o planejador é apenas parte do sistema. Um sistema onde todas
as tabelas sejam fisicamente ordenadas incorre em grande trabalho nas
escritas; por isso mesmo, nenhum sistema SQL que eu conheça ordena
tabelas a menos que comandado explícita e manualmente para isso.
Um sistema onde isso ocorre, como era o caso dos navigacionais ou dos
grafos, tende a ser globalmente lento para escrita, o que
inevitavelmente afetará todas as consultas — os discos e caches
estarão ocupados em manter a organização das tabelas, e portanto todas
as consultas que não se beneficiarem diretamente da organização
sofrerão. É uma tendência natural humana evitar essas consultas
prejudicadas, e foi esse tipo de situação que levou ao Codd criar o
modelo relacional.
Ah, e desculpe por não ter explicado isso melhor antes.
> Acusar um BD de fazer otimização precoce sem conhecê-lo é uma crítica
> precoce.
Acusar um DBA de desconhecer um SGBD (BD são os dados, não o programa
que os gere) sem conhecer sua carreira é um preconceito, que por
definição é precoce.
> É 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.
Ainda estou para achar o tal artigo. Eu agradeceria muito um URI ou
outra indicação de como o encontrar.
> 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, sem ofensa — mas sempre que você trouxe essas reclamações
sobre o desempenho do PostgreSQL, pedimos mais informações, e você
nunca as trouxe. Pelo menos, não quando eu acompanhava ativamente a
lista, nem nas pesquisas que cheguei a fazer — me perdoe se já tiveres
preenchido essa lacuna. De qualquer maneira, tudo bem, é um direito
teu não abrir essas informações. Mas também é um direito nosso, dados
os muitos mal-entendidos de tua parte tanto sobre o PostgreSQL, quanto
sobre o modelo relacional, e aparentemente até sobre o MS SQL Server,
concluir tentativamente, como fazemos, que o problema é que tua
aplicação foi toda construída para MS SQL Server e apenas parcialmente
portada para PostgreSQL. O que é natural e humano, devido às lacunas
de conhecimento aparentes.
Todos temos lacunas de conhecimento, e provavelmente as minhas são bem
maiores que as tuas, mas provavelmente em áreas diferentes. De
qualquer maneira, é importante reconhecê-las.
Infelizmente, parece que não estarei na conferência deste ano. Creio
que os desentendimentos entre tu e a comunidade são tão grandes, que a
lista se torna um meio ineficiente para esclarecê-los, e gostaria de
um tête à tête na frente dum computador (com pessoas mais entendidas
do que eu por perto) para o fazer.
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 gTalk: xmpp:[email protected]
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3 MSN: msnim:[email protected]
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
