2016-08-25 11:12 GMT-03:00 Fabiano Machado Dias <fabi...@wolaksistemas.com.br>: > >> Não há limite, exceto praticidade. E mesmo assim, às vezes deixa-se >> de usar por ‘otimização precoce’: teme-se o efeito da propagação duma >> chave com, digamos, quatro ou cinco atributos por tabelas filhas >> (chaves estrangeiras), mas deixa-se de levar em conta todas as junções >> e índices que uma chave natural economiza. > > Este é o ponto onde se deve ter cuidado, eu já vi um ERP onde no nível mais > baixo da contabilidade (rateio de centro de custo) a chave primária da > tabela tipo por volta de 15 campos!!!
Para isso que se criam chaves artificiais, que nem precisam ser primárias. Na verdade, o ideal é que não sejam, para que o modelo fique mais claro e para que nunca se esqueça de definir ao menos uma chave natural. > Imagine como era trabalhar com uma modelagem desta! Com um ferramental adequado, não devia ser problema algum. Eu fazia isso com COPYs Cobol, sem dramas. Vi muito javeiro reclamando, e questionava-os por que o Java seria tão inferior ao Cobol para fazer algo tão básico. O que tem de ver é se essa propagação de chaves compostas não seria um problema de armazenamento ou consumo de memória. Poderia em tese ser, e geralmente não é, até por evitar criar campos e índices adicionais para as chaves artificiais. Agora, se o ferramental é ruim ou mal usado… infelizmente, uma situação comum. Espere problemas com usuários mais ingênuos de ORM, por exemplo. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
