Em Sexta-feira, 11 de Abril de 2014 20:39, Douglas Fabiano Specht
<[email protected]> escreveu:
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
Amigo, boa tarde!
Ao se fazer o particionamento "vertical" de uma tabela, dividindo-a em dois
grupos de colunas, você deve levar em conta não só o seu número e tamanho, mas
também o bom senso.
Normalmente se separa a tabela em uma relação com os atributos mais acessados e
obrigatórios, e outra tabela com os atributos menos necessários e opcionais.
Desta forma reduz-se a necessidade de fazer junções.
Analise se a herança resolve o seu problema, ou se visões ou visões
materializadas poderiam ser empregadas de forma satisfatória.
Cordialmente,
Cláudio Leopoldino
postgresqlbr.blogspot.com/
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
