2010/1/4 Mozart Hasse <mozart.ha...@usa.net>:
>
> Bancos de dados que usam SQL assumem que a chave exportada é a chave
> primária a não ser que se explicite o contrário
Uai, e quem está preocupado com isso?
Na maioria dos casos, não faz diferença a chave primária ser natural,
seja porque não será exportada, seja porque os volumes são
irrelevantes para aquela implementação física. Nesses casos, não há o
menor problema em exportar a chave primária.
Para a minoria (geralmente) dos casos em que é necessária, em SQL, uma
chave artificial (e explicitada ao usuário), ela pode tranqüilamente
ser a primária, não faz a menor diferença que a natural seja declarada
sem ser primária.
> Expus casos em que uma chave artifical exportada tem
> vantagens sobre as chaves compostas naturais correspondentes.
Perfeito, há casos, mas são minoritários e não excluem as chaves
naturais, compostas ou não.
> Você defendeu e reafirma que "geralmente chave artificial é desnecessária".
> Não me culpe
> por não adivinhar que está se referindo à exceção usando termos como
> "geralmente".
Pelo contrário, a exceção é precisar de chave artificial. Talvez
prestemos muita atenção nas exceções em termos de quantidade de
tabelas, porque as exceções acabam representando o maior volume de
dados.
Aliás, não o culpo de nada… só me surpreendo de como não consigo me
fazer entender.
> Nunca falei em *sempre* usar chaves artificiais. Novamente se o seu problema
> é inclusão desnecessária de campos numa tabela, critique o mau hábito,
> não o uso de chaves artificiais, que não tem nada a ver com isso.
Como não tem, se uma chave artificial é um atributo a mais? E se é
freqüentemente abusado?
> 1. Tamanho dos índices que incluem os campos da chave primária. Tamanho
> menor implica em uso mais frequente;
Sim, onde há volume que faça diferença.
> 2. Tamanho do comando SQL em consultas com várias junções, facilitando a
> vida do compilador e do otimizador;
Irrelevante… tokenizado.
> 3. Melhor estimativa de quantos registros cada condição irá retornar,
> melhorando o desempenho.
Estou para ver alguma diferença prática. Muito me surpreenderia se
houvesse alguma nas tabelas menores, que são a maioria.
>> > Se quer ler e entender o modelo, use a representação conceitual (modelo
>> > lógico).
>
>> Que, normalmente, não é mantido e, quando é, geralmente é apenas uma
>> reversa do físico, ocultando mais do que explicando.
>
> Novamente: se o seu problema é má documentação, critique o mau hábito,
> não as chaves artificias, que não tem nada a ver com isso.
Na verdade, a questão aí nem é documentação em si… é o próprio SQL que
não suporta a divisão entre conceitual e físico, e o ferramental em
torno não ajuda tanto quanto deveria.
> Lendo o que está escrito, não achei o que a "maioria" está fazendo de
> errado
Chaves artificiais à exclusão das naturais, essencialmente. E além
delas, em muitos casos.
Perdão por não me explicar mais clara e precisamente.
> nem seus critérios para medir quem é maioria e quem é minoria.
Só a minha experiência, e a de muitos colegas.
>> Falando sério, é só ver a inconsistência dos nomes de atributos?
>
> Brincou com a pergunta que mais deveria ser levada a sério. :-/
Pelo contrário.
> Não podemos esquecer que os sistemas servem para resolver *problemas*, não
> para gerar diagramas conceitualmente "perfeitos".
E qual problema exige os nomes inconsistentes dos atributos nas
relações do dicionário de dados do Oracle?
> Agora, não tente me convencer de que a "maioria" não coloca
> desempenho na lista de prioridades.
Nem tentarei. Coloca, mas equivocadamente. Não faz sequer um teste
para verificar se as regrinhas que aprendeu de ouvido se aplicam a seu
caso.
> Não, não concordaria.
Não estivesses tão quente com a polêmica… ;-)
Gostaria de escrever a respeito, também. O número talvez seja
absurdo, mas o fato de que há imensos desperdícios não é.
> De novo usando como regra geral ("geralmente") o oposto ao praticado por
> vários bancos de dados, que oferecem a opção de escolher o nível de
> isolamento exatamente
> por causa do desempenho.
Não oposto, criastes um espantalho.
A opção existir não significa que se aplica tão geralmente.
Aliás, geralmente o valor por omissão é um nível de isolamento abaixo
do serializável. O que é ótimo para prototipar um aplicativo ou para
dados isolados, mas nem tanto para sistemas maiores. Suspeito de que
a razão seja fazer bonito em testes de desempenho e evitar afugentar
programadores, mas gostaria de saber a razão exata.
> Se ganho de desempenho pelo nível de isolamento não fosse relevante,
> não seria uma opção mantida em tanto bancos de dados diferentes, incluindo
> o Postges.
Relevante, sim, mas em que casos?
Na minha experiência, e de vários colegas, o uso de níveis de
isolamento inferior ao serializável dá um ganho geralmente
insignificante, mas gera perdas significativas ao acabar levanto
desenvolvedores a colocarem conferências de
>> Claro? mas qual a proporção de tabelas que têm filhas, e que são
>> menores que as filhas, e cujas filhas são de tamanhos significativos?
>
> Por amostragem no meu caso vai de 30 a 70%.
Isso seria meio absurdo. Como 70% das tabelas terão filhas de
tamanhos significativos, e maiores que o de suas mães? Talvez nalguns
casos, mas proporcionalmente me supreenderia se fossem muitos casos.
> Se desempenho for requisito, basta
> *uma* para te obrigar a alterar o modelo para ter uma aplicação viável do
> ponto de vista do cliente.
Altere, mas não estrague o resto do modelo.
>> Non sequitur.
>
> Já que não "concorda" com a teoria (ou não entendeu minha explicação),
> sugiro que verifique o resultado na prática.
Quinze anos verificando… o argumento certamente é falacioso, como apontei.
> Se o problema é esse, critique a cultura de má modelagem, de preferência
> sendo específico, e não o uso das chaves seriais, que não tem nada a ver com
> isso.
Claro que tem! A má modelagem se traduz no abuso das chaves artificiais.
>> Para bom entendedor? fica claro que o que exijo é chave natural,
>> independente de ser primária ou alternativa, e que prefiro que não
>> haja artificial a não ser que o desempenho exija.
>
> Bom saber que pelo menos concordamos em alguma coisa.
Caramba, então ou sou muito mau explicador, ou… para bom entendedor…
tanta discussão para nada?
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 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
Sent from Sao Paulo, SP, Brésil
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
