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 < [email protected]> escreveu: > 2016-08-25 11:12 GMT-03:00 Fabiano Machado Dias < > [email protected]>: > > > >> 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:[email protected] > +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 > BRAZIL GMT−3 MSN: msnim:[email protected] > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
