Leandro,
> > Quer embutir essa tralha
> > toda na chave primária e em todas as chaves estrangeiras por questão de
> > purismo conceitual?
> Não. Nunca falei isso. Falei que geralmente chave artificial é
> desnecessária; não que é sempre desnecessária. E, aliás, que o que
> menos me importa é qual seja a chave primária, ou qual chave será
> ?exportada? (não nesta discussão, talvez).
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 (nunca vi isso ocorrer em mais do que
0,02% dos casos). Expus casos em que uma chave artifical exportada tem
vantagens sobre as chaves compostas naturais correspondentes. 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, uma chave artificial (que não é chave,
> conceitualmente) tem de ser definida *além* das naturais, e portanto
> sempre será gordura. Pode ser uma gordura necessária, mas em alguns
> casos, não todos.
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.
> Aliás, que diferença faz o tamanho da chave para a maioria das
> tabelas, que não tem filhas de tamanho significativo? Evitar junções
> desnecessárias costuma ser mais importante.
1. Tamanho dos índices que incluem os campos da chave primária. Tamanho
menor implica em uso mais frequente;
2. Tamanho do comando SQL em consultas com várias junções, facilitando a
vida do compilador e do otimizador;
3. Melhor estimativa de quantos registros cada condição irá retornar,
melhorando o desempenho.
> > 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.
> (...) Não percebeu, ou esqueceu,
> que não estou impondo verdades absolutas, mas derrubando regrinhas
> estúpidas que são úteis nalguns casos mas prejudicam na maioria. Veja
> que em nenhum lugar tentei proibir chaves artificiais; só disse que
> elas são úteis numa minoria dos casos onde são usadas hoje. Parabéns
> por ter um sistema grande e longevo. Mas não use tua experiência e
> capacidade para desprezar a experiência e capacidade de outros. Leia
> o que foi escrito, (...)
Lendo o que está escrito, não achei o que a "maioria" está fazendo de
errado, nem seus critérios para medir quem é maioria e quem é minoria.
> > Catálogo do Oracle mal modelado? Quando apresentar algum mais normalizado
que
> > faça o mesmo que ele e ainda por cima tenha o mesmo desempenho, avise.
> Simples: o do PostgreSQL. Mas isso foi apenas sacanagenzinha minha?
> Falando sério, é só ver a inconsistência dos nomes de atributos?
Brincou com a pergunta que mais deveria ser levada a sério. :-/
Não podemos esquecer que os sistemas servem para resolver *problemas*, não
para
gerar diagramas conceitualmente "perfeitos". A organização conceitual
*interna*
da aplicação é exatamente o que o usuário não vê. Citei um caso em que o
desempenho
é o requisito e foi claramente priorizado. Chaves artificiais também servem
para
melhorar desempenho em muitos casos, como os que citei. Se o seus requisitos
são
outros, não as use. Agora, não tente me convencer de que a "maioria" não
coloca
desempenho na lista de prioridades.
> De fato não li o referido estudo, e não tenho a pachorra de buscá-lo
> agora. O interessante é que, para quem tem experiência na área, não
> parece tão absurdo quanto deveria. Creio que tu mesmo concordarias,
> não estivesses tão quente com a polêmica.
Não, não concordaria.
> >> Nível de isolamento serializável, e de quebra a aplicação fica mais
> >> robusta.
> >
> > E mais lenta, especialmente em acessos concorrentes. Nem todo mundo tem
tempo,
> > dinheiro ou motivo para esperar.
> Nem tão mais lenta quanto se pensa, nem todo mundo tem o gargalo aí.
> Geralmente, a aplicação mais robusta e melhor pensada mais do que
> compensaria os custos computacionais da serializaçã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. 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.
> > Tamanho do índice entra na conta, especialmente com muitos registros
tanto na
> > tabela pai quanto na filha.
> 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%. 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.
> > http://www.postgresql.org/docs/8.4/static/planner-stats.html
(...)
> Até aí, morreu o Neves?
(...)
> 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.
> Vou falar algo que sempre falo, principalmente quanto a Java: o
> problema não é a ferramenta, é a cultura que gira em torno de si e
> determina seu uso.
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.
> 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.
Mozart Hasse
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
