Em 24 de junho de 2015 16:02, Márcio A. Sepp <mar...@zyontecnologia.com.br> escreveu: > > Deu pro gasto! Rsss Muito obrigado!
De nada. > Só pra te falar, minhas tabelas são +/- assim: > Tabela1 > * pk_tab1 > > Tabela2 > * pk_tab1 > * pk_tab2 > > Tabela3 > * pk_tab1 > * pk_tab2 > * pk_tab3 > ... > > Tabela6 > * pk_tab1 > ... > ... > * pk_tab12 > > Na prática... lá pelo 6 nível, eu tenho uma tabela com 12 campos na chave. > Todos os relacionamentos estão em cascade. O que me assustou é a quantidade > de campos na chave primária e os impactos disso no banco de dados... Acaso > tens alguma medição do desempenho de um banco escrito desta forma? Ah, agora entendi. Antes havia entendido que só no último nível você tinha essas chaves grandes. Eu não tenho medição, nunca fiz algo desse tamanho. Mas lembre-se que otimização precoce é a raiz de toda sorte de males: se essa modelagem é a conceitualmente mais adequada, implante assim, e se constatar problemas para a frente acrescente as chaves artificiais. É muito mais complicado definir com chaves artificiais e tentar converter para naturais depois que teus dados já estão inconsistentes por falta de chaves naturais. -- 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
