(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
