Leandro, > 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. > Os problemas do CNPF são outros, geralmente: gente que não tem CNPF > pode até ter conta bancária, por exemplo mulheres casadas com conta > conjunta com o marido. E isso pode mudar a qualquer momento quando os requisitos do seu sistema mudarem. 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? Quer embutir essa tralha toda na chave primária e em todas as chaves estrangeiras por questão de purismo conceitual? Quando eu trocar o tamanho do campo vou ter de criar um script monstruoso que levará horas ao invés de 30 segundos digitando uma linha. Quando alguém digitar errado o nome do cara durante o cadastro e notar isso no mês seguinte, depois de lanças algumas dezenas de notas, devo deixar o cliente esperando a emissão de nota ficar parada porque o banco de dados precisa aplicar o cascade nas 47 filhas para o modelo não ser prejudicado? Na-na-ni-na-não. > > Exemplos pf, engorda a base? Pelo que entendo facilita até a maneira que > > o banco trabalha. > Em alguns casos, já citados, sim, por limitações do SQL. Mas na > maioria dos casos é um atributo e um índice a mais sem necessidade, e > mais junções. 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. > > Obscurece o modelo? Por favor seja mais específico. > > Quem lê um modelo com chaves naturais entende tudo; quem lê um modelo > com chaves artificiais tem de adivinhar muita coisa. Se quer ler e entender o modelo, use a representação conceitual (modelo lógico). Quando puser para funcionar, terá de lidar com o modelo *físíco*, com todas as tabelas, índices, chaves artificiais, índices, triggers, visões materializadas e qualquer outra coisa que sirva para deixar a aplicação com um desempenho decente. > Eu diria que é para evitar ser amaldiçoado por todas as gerações > futuras de usuários, programadores e analistas, sem falar nos DBAs. Estou pra conhecer um DBA que goste de rasgar SLAs com cláusulas de tempo de resposta mínimo e mande todo mundo parar de trabalhar para esperar o banco fazer um DELETE CASCADE numa tabela com mais de 100000 registros. Estou também para conhecer um DBA que seja contratado por alguém que se dê ao luxo pagar um cara qualificado para dizer para o cliente "senta e chora" quando identificar deadlocks causados por purismos conceituais. > Claro! Mas eu tenho o pressentimento de que, como está, teu sistema > dificilmente crescerá muito, e continuará a ser mantido por ti, então > nada do que falei se tornará visível. 3 anos é pouco pra você?! Tá bom, que tal o sistema que mantenho hoje, que tem uns 15? 900 tabelas tá bom pra você ou é meio pequenininho pra entrar na conta? > Na verdade, mesmo os grandes ERPs têm péssimos modelos. Até o > catálogo da Oracle é mal modelado. 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. > Dá para ir tocando, mas são custos ocultos. > Alguém os estimou globalmente em US$1,2T por ano. Isto é apenas um número sem fonte (vulgo chute) com um valor cheio de zeros. Chutes não vão convencer ninguém a mudar de idéia nem vão justificar qualquer abordagem que se apresente. >> especialmente se você quiser usar a chave para >> identificar alterações concorrentes sobre o mesmo registro > 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. > Agora me dei conta? será que teus problemas recorrentes de desempenho > não são por controle de transações na aplicação? Não, pois faço os testes de desempenho com uma única conexão a um servidor dedicado. >> A melhoria é grande demais para ser ignorada, pois >> quase todos os índices ficarão menores > Ou melhor, depende. Tabela mãe pequena e pouco usada com tabelas > filhas grandes, pode ser, se não forçar junções demais. Tamanho do índice entra na conta, especialmente com muitos registros tanto na tabela pai quanto na filha. > Mas sempre haverá um índice a mais, tanto em disco quanto em memória, > ocupando também cache e exigindo atualizações. O que só seria problema se a atividade mais frequente fosse atualizar as tabelas ao invés de consultá-las. >> 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: 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. 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. >> Além do mais, ninguém falou em não declarar chaves alternativas para >> evitar duplicidades. > Mas é o que costuma acabar acontecendo. 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. Mozart Hasse _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
