Configure teu cliente para as respostas padrão, por favor… RFC 1855.
2009/12/30 Wolak Sistemas - Fabiano Machado Dias <[email protected]>: > Sei disso. Mas não é o tipo de uso que você esta imaginando. Não estou imaginando, é que não há mais usos legítimos para OIDs. > Não evita duplicidade? Me de um exemplo ou um case por favor, porque > então a documentação está errada e tudo o que li tb. Sim, escreve-se muita bobagem. Por exemplo, imagine um cadastro qualquer, com um código incremental e um nome que tem de ser único. É um exemplo simplérrimo, só para mostrar o problema. 1 José 2 José 3 José Pronto, como foi que a chave artificial evitou duplicidade? Nesse exemplo, precisaria agregar à chave natural outras informações, como data de nascimento, filiação &c. > Uma chave natural por exemplo CPF, nada te garante que no futuro não irá > mudar o padrão e ali o teu modelo foi pro saco. E qual o problema? ON UPDATE CASCADE e DEFERRABLE INITIALLY DEFERRED resolvem o problema, e este último até se adequa melhor ao modelo relacional. Particularmente, prefiro saber quando muda uma chave. Melhor que as alterações sejam explícitas que implícitas. 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. > 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. > 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. > Como hj estamos envolvidos com outros módulos do sistema já não vale a > pena ficar mudando apenas para ficar "bonito e no padrão". Eu diria que é para evitar ser amaldiçoado por todas as gerações futuras de usuários, programadores e analistas, sem falar nos DBAs. > Essa afirmação é bem contundente, mas como esse sistema já está a 3 anos > rodando no primeiro cliente (indústria com faturamento médio de 5 milhões > mensais) acredito que já estamos no meio do caminho e se o modelo se mostrou > eficiente até agora, duvido que vou ter problemas daqui pra frente, de > qualquer forma vou guardar esse email e daqui a alguns anos tiramos a prova. 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. Na verdade, mesmo os grandes ERPs têm péssimos modelos. Até o catálogo da Oracle é mal modelado. Dá para ir tocando, mas são custos ocultos. Alguém os estimou globalmente em US$1,2T por ano. > "- Uma pessoa sem bom senso não se preocupa com melhores práticas > - Uma pessoa com bom senso e pouca experiência procura aprender e utilizar > as melhores práticas > - Uma pessoa com bom senso e muita experiência sabe quando não utilizar as > melhores práticas" Exato. Porque ele estava se referindo a essas ‘melhores práticas’ falsas, como as que você usou. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:[email protected] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:[email protected] Sent from Sao Paulo, SP, Brazil _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
