Em 26 de março de 2014 19:19, Guimarães Faria Corcete DUTRA, Leandro < [email protected]> escreveu:
> 2014-03-26 18:15 GMT-03:00 Douglas Fabiano Specht < > [email protected]>: > > > > Em 26 de março de 2014 18:00, Guimarães Faria Corcete DUTRA, Leandro > > <[email protected]> escreveu: > >> Mas parece mais um caso para particionamento. > >> > > Mas o particionamento de tabela é horizontalmente(dados), precisava > > particionar verticalmente(colunas) > > Mas tua descrição do que querias falava em volume excessivo de dados. > Isso se resolve com particionamento, a menos que você possa normalizar > a base -- e mesmo assim pode ainda precisar de particionamento. > > Visões e gatilhos podem ajudar a dividir em atributos sem normalizar, > ou até normalizando, mas dá mais trabalho para evitar mudar o > aplicativo. > > > -- > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (61) 3546 7191 gTalk: xmpp:[email protected] > +55 (11) 9406 7191 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 > Boa anoite galera, para finalizar o post e colocar a solução, para futuras pesquisas, vou utilizar herança (inherit), onde vou pegar a tabela docfiscal por exemplo que possui atualmente 124 campos, e dividi-la em 2 de 62, onde a tabela filha irá se chamar docfiscal, e a pai docfiscal_pai. como por herança a tabela filha herda os objetos do pai, desta maneira irá ficar totalmente transparente para aplicação ou usuário, pois quando fizer um insert, update, delete, ou um select, sempre faço na docfiscal, que ira trazer os seus objetos mais os objetos da docfiscal_pai. Deixamos os desenvolvedores felizes [1], quando conseguimos arrumar algo feito por eles e que principalmente nao irao precisar implementar nada. [1]. Dessa maneira me resolve a questão de tabelas onde os programadores se "empolgaram" no modelo ER. Ja para particionar essas tabelas quando o volume de registros chegar em torno de uns 10.000.000 de registros, ainda vou pensar, mas acho que fazer trigger por data é o que mais convêm, mas também deve ser transparente para a aplicação, logo vou ainda estudar um pouco mais.... Uma pergunta mais voltado ao pessoal que trabalha com modelagem. Existe alguma regra ou sujestão\boas praticas de quantidade de campos para uma tabela? algum link\documento?? -- Douglas Fabiano Specht
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
