Depende, lá como eu disse as chaves compostas foram usadas de forma errada, era uma estrutura de grupo, empresa, filial, unidade + chave_negocio_tabela, então de cara qualquer PK já tinha no mínimo 5 campos!
Sem contas outras gambiarras que não vem ao caso aqui. Em 25 de agosto de 2016 11:33, Gustavo <gustavo.14042...@gmail.com> escreveu: > (lembro que eram quase 4 mil tabelas), ouch !!!!! > > o meu só tem 1.000 tabelas... será que terei problemas com performance > ???? > ᐧ > > Em 25 de agosto de 2016 11:26, Fabiano Machado Dias < > fabi...@wolaksistemas.com.br> escreveu: > >> O maior problema era o inchaço do banco (lembro que eram quase 4 mil >> tabelas), além da escrita de consultas, um join básico ficava gigante, >> imagina então algo maior como um SPED! >> >> Não tenho mais contato com esse sistema, mas sei que até hoje sofre com >> problemas de performance nos clientes que usam. >> >> >> >> Em 25 de agosto de 2016 11:20, Guimarães Faria Corcete DUTRA, Leandro < >> l...@dutras.org> escreveu: >> >>> 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 >>> >> >> >> _______________________________________________ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
