2009/12/30 Mozart Hasse <mozart.ha...@usa.net>: >> Particularmente, prefiro saber quando muda uma chave. Melhor que as >> alterações sejam explícitas que implícitas. > > Quer saber quando a chave muda? Registre alterações via trigger numa > tabela de histórico. Teu modelo não tem nenhuma obrigação de mudar > por causa desse desejo.
Hm, não me expliquei bem. Creio que a aplicação deve saber quando uma chave natural exportada mudar — ou melhor, o programador. Não é uma alteração comum, e o custo de pensar sobre ela vale a pena os benefícios. > E isso pode mudar a qualquer momento quando os requisitos do seu sistema > mudarem. Naturalmente — e, mais uma vez, prefiro mudanças explícitas a implícitas. > Conheci sistemas que precisaram colocar até nome da mãe na chave > alternativa da tabela de pessoas para evitar duplicidades. Que tal fazer > isso na minha tabela de pessoas, com 47 filhas? Até mais que o nome da mãe… poderia chegar ao ponto do DNA, das digitais, da íris entrarem para a chave. A idéia da chave artificial foi justamente lidar com esse tipo de situação. Nunca foi implementada corretamente, mas mesmdo do jeito que está pode ser útil e, até, necessário. > 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). > Em TODOS os bancos de dados o tamanho do índice conta na decisão de usá-lo > ou não, e uma chave serial de 2, 4 ou 8 bytes jamais será maior do que > qualquer chave natural que se encontre para a mesma tabela. Portanto, usar > chaves naturais para fazer FKs aumenta sim o tamanho dos índices e tem toda a > chance de igualar ou piorar o desempenho. 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. 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. > 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. > 3 anos é pouco pra você?! Tá bom, que tal o sistema que mantenho hoje, que > tem uns 15? Melhorando! > 900 tabelas tá bom pra você ou é meio pequenininho pra entrar na conta? A quantidade de tabelas parece interessante… mas você já está na polêmica pela polêmica, caro Herr Hasse. 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, não o que te irritou no passado. Parece que não estás lendo o que escrevi, mas algo que algum sabichão falou sabe-se lá quando e ficou atravessado em tua garganta. > 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… > Isto é apenas um número sem fonte (vulgo chute) com um valor cheio de zeros. 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. Aliás, quero escrever um pouco a respeito, dia desses… todas as oportunidades desperdiçadas, por exemplo com programação funcional e de pilha, processadores específicos, computação hospedeiro-terminais, sistemas abertos e livres, processadores RISC, Unix e Plan9, métodos formais, sistemas relacionais… o mundo poderia ser bem melhor. >> 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. > Não, pois faço os testes de desempenho com uma única conexão a um servidor > dedicado. Hm, isso não seria um teste válido para muitos casos… mas é claro que conheces tua situação melhor que qualquer um de fora. > 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? > O que só seria problema se a atividade mais frequente fosse atualizar as > tabelas ao invés de consultá-las. Ou se as atualizações não forem tão menos freqüentes que as consultas. O que não é uma situação tão inaudita assim. >>> e com distribuição estatística mais >>> evidente (do ponto de vista do banco de dados) usando uma PK numérica >>> de um só campo. > >> Não. > > Eu poderia dar uma resposta irrelevante como "Sim.", mas prefiro contribuir > justificando meus motivos devidamente expostos na documentação: Tenho de confessar que planejei me aproveitar de uma eventual resposta tua, e acertei… ;-) > http://www.postgresql.org/docs/8.4/static/planner-stats.html > "One component of the statistics is the total number of entries in each table > and index, as well as the number of disk blocks occupied by each table and > index." > > Logo, sim, o tamanho do índice conta, e muito, no seu uso. Até aí, morreu o Neves… > Esta mesma página explica que as estatísticas consultadas são as da > pg_stats, que organizam os dados de UMA COLUNA por registro. Logo, se eu > quiser estimar > quantos registros filhos há em média para cada registro pai, a estimativa com > um > único campo será muito mais precisa que qualquer chave natural composta que se > apresente. Non sequitur. > Não. Se o problema é esse, critique a falta de chaves alternativas, e não o > uso das chaves seriais, que não tem nada a ver com isso. 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. O problema não é a existência do SERIAL, é seu uso — e abuso. 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. -- 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, Brazil _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
