[pgbr-geral] auto relacionamento
Pessoal, Tenho uma tabela que contém apenas 1 pk, 1 unique e 4 fks (sendo uma de auto relacionamento), essa tabela está com 400 mil registros. Analisando o tamanho, a tabela está com 200 MB de dados e 38 GB de indices, estava assim antes, aí rodei um vacuum full dessa tabela, e o tamanho caiu, mas 1 semana depois voltou a ter os mesmos 38 GB. Como o postgres trata os *auto relacionamentos*? Sinceramente nunca vi um auto relacionamento antes, então não sei dizer se o problema que estou tendo tem a ver com isso. []s Danilo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] auto relacionamento
2014-06-20 11:54 GMT-03:00 Danilo Silva danilo.dsg.go...@gmail.com: Como o postgres trata os *auto relacionamentos*? Normalmente. Sinceramente nunca vi um auto relacionamento antes, então não sei dizer se o problema que estou tendo tem a ver com isso. Por que teria? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691ICQ/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
Re: [pgbr-geral] auto relacionamento
Tenho uma tabela que contém apenas 1 pk, 1 unique e 4 fks (sendo uma de auto relacionamento), essa tabela está com 400 mil registros. Analisando o tamanho, a tabela está com 200 MB de dados e 38 GB de indices, estava assim antes, aí rodei um vacuum full dessa tabela, e o tamanho caiu, mas 1 semana depois voltou a ter os mesmos 38 GB. Como você fez essa análise de tamanho? Que comandos rodou e qual versão do PostgreSQL está usando? O comando VACUUM FULL não diminui tamanho de índices, mas te tabelas. Para diminuir tamanho de índices usa-se o REINDEX. Como o postgres trata os *auto relacionamentos*? Sinceramente nunca vi um auto relacionamento antes, então não sei dizer se o problema que estou tendo tem a ver com isso. Auto-relacionamento é uma entidade de banco de dados comum em PostgreSQL. Não vejo onde está o problema, se é que você realmente tem algum. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] auto relacionamento
2014-06-20 12:13 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com: O comando VACUUM FULL não diminui tamanho de índices, mas te tabelas. Para diminuir tamanho de índices usa-se o REINDEX. Só uma correção. Nas versões mais recentes (a partir da 9.0, se não me engano), o VACUUM FULL (VF) não precisa ser precedido de REINDEX, o próprio VF reescreve os índices também e diminui sim seus tamanhos. Já nas versões anteriores, ele é praticamente requirido, já que antes o VF piorava a fragmentação. Mas eu diria para nem usar VF em versões anteriores, basicamente nunca. E até nas mais recentes, apenas quando realmente comprovada a necessidade, muitas tabelas que sofrem muita atualização pode se beneficiar de um espacinho a mais, talvez até mesmo seja uma vantagem aumentar o fillfactor. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] auto relacionamento
Em 20 de junho de 2014 13:15, Matheus de Oliveira matioli.math...@gmail.com
escreveu:
2014-06-20 12:13 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com
:
O comando VACUUM FULL não diminui tamanho de índices, mas te tabelas.
Para diminuir tamanho de índices usa-se o REINDEX.
Só uma correção. Nas versões mais recentes (a partir da 9.0, se não me
engano), o VACUUM FULL (VF) não precisa ser precedido de REINDEX, o próprio
VF reescreve os índices também e diminui sim seus tamanhos.
Já nas versões anteriores, ele é praticamente requirido, já que antes o VF
piorava a fragmentação. Mas eu diria para nem usar VF em versões
anteriores, basicamente nunca. E até nas mais recentes, apenas quando
realmente comprovada a necessidade, muitas tabelas que sofrem muita
atualização pode se beneficiar de um espacinho a mais, talvez até mesmo
seja uma vantagem aumentar o fillfactor.
A versão é PostgreSQL 8.4.10, compiled by Visual C++ build 1400, 32-bit
em windows;
A tabela sofre updates constantes;
O vacuum foi rodado da seguinte maneira (pelo pgadmin): vacuum full verbose
analyse nome_tabela;
Para saber o tamanho da tabela rodei a query abaixo:
SELECT
n.nspname as Schema, c.relname as Name,
CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' WHEN 'i' THEN
'index' WHEN 'S' THEN 'sequence' WHEN 's' THEN 'special' END as Type,
pg_catalog.pg_get_userbyid(c.relowner) as Owner,
pg_catalog.pg_relation_size(c.oid) as SIZE Tabela,
pg_catalog.pg_total_relation_size(c.oid) -
pg_catalog.pg_relation_size(c.oid) as SIZE Indice,
pg_catalog.pg_total_relation_size(c.oid) as SIZE Total,
pg_catalog.pg_size_pretty(pg_catalog.pg_relation_size(c.oid)) as TAM
Tabela,
pg_catalog.pg_size_pretty(pg_catalog.pg_total_relation_size(c.oid) -
pg_catalog.pg_relation_size(c.oid)) as TAM Indice,
pg_catalog.pg_size_pretty(pg_catalog.pg_total_relation_size(c.oid)) as TAM
Total,
pg_catalog.obj_description(c.oid, 'pg_class') as Description
,pg_catalog.pg_total_relation_size(c.oid)
, 'SELECT '''||c.relname||''', COUNT(*) FROM '||c.relname||' UNION ALL ' AS
contador
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r')
AND n.nspname 'pg_catalog'
AND n.nspname 'information_schema'
AND n.nspname !~ '^pg_toast'
AND pg_catalog.pg_table_is_visible(c.oid)
ORDER BY 5 DESC, 1,2;
[]s
Danilo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] auto relacionamento
O comando VACUUM FULL não diminui tamanho de índices, mas te tabelas. Para diminuir tamanho de índices usa-se o REINDEX. Só uma correção. Nas versões mais recentes (a partir da 9.0, se não me engano), o VACUUM FULL (VF) não precisa ser precedido de REINDEX, o próprio VF reescreve os índices também e diminui sim seus tamanhos. É verdade. Mas se eu tiver problemas de inchaço com um índice e não com a tabela, eu usaria REINDEX antes do VACUUM FULL. Já nas versões anteriores, ele é praticamente requirido, já que antes o VF piorava a fragmentação. Mas eu diria para nem usar VF em versões Inchaço, correto? anteriores, basicamente nunca. E até nas mais recentes, apenas quando Existe o comando CLUSTER que faz mais ou menos o que a versão mais moderna do VACUUM FULL faz, com o adicional de ordenar a tabela por um índice. realmente comprovada a necessidade, muitas tabelas que sofrem muita atualização pode se beneficiar de um espacinho a mais, talvez até mesmo seja uma vantagem aumentar o fillfactor. Aí a discussão vai longe. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] auto relacionamento
A versão é PostgreSQL 8.4.10, compiled by Visual C++ build 1400,
32-bit em windows;
É bom atualizar. A versão 8.4.21 está disponível hoje, ou seja, 11
releases de correções de bugs já foram lançadas após essa que você está
rodando.
Antes que você pergunte, sim, a compatibilidade com seus dados e
aplicações atuais está garantida.
Antes ainda que você pergunte, sim, considere migrar para as versões
mais 9.3 ou já para 9.4 quando sair, porque a 8.4 perderá suporte este ano.
A tabela sofre updates constantes;
Esperava-se mesmo que ela fosse gordinha.
O vacuum foi rodado da seguinte maneira (pelo pgadmin): vacuum full
verbose analyse nome_tabela;
Após o VACUUM FULL na versão 8.4 é melhor fazer um REINDEX.
Aliás, mantenha o autovacuum corretamente *ligado* e nunca mais faça
VACUUMs FULLs.
Para saber o tamanho da tabela rodei a query abaixo:
SELECT
n.nspname as Schema, c.relname as Name,
CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' WHEN 'i' THEN
'index' WHEN 'S' THEN 'sequence' WHEN 's' THEN 'special' END as Type,
pg_catalog.pg_get_userbyid(c.relowner) as Owner,
pg_catalog.pg_relation_size(c.oid) as SIZE Tabela,
pg_catalog.pg_total_relation_size(c.oid) -
pg_catalog.pg_relation_size(c.oid) as SIZE Indice,
pg_catalog.pg_total_relation_size(c.oid) as SIZE Total,
pg_catalog.pg_size_pretty(pg_catalog.pg_relation_size(c.oid)) as TAM
Tabela,
pg_catalog.pg_size_pretty(pg_catalog.pg_total_relation_size(c.oid) -
pg_catalog.pg_relation_size(c.oid)) as TAM Indice,
pg_catalog.pg_size_pretty(pg_catalog.pg_total_relation_size(c.oid)) as
TAM Total,
pg_catalog.obj_description(c.oid, 'pg_class') as Description
,pg_catalog.pg_total_relation_size(c.oid)
, 'SELECT '''||c.relname||''', COUNT(*) FROM '||c.relname||' UNION ALL '
AS contador
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r')
AND n.nspname 'pg_catalog'
AND n.nspname 'information_schema'
AND n.nspname !~ '^pg_toast'
AND pg_catalog.pg_table_is_visible(c.oid)
ORDER BY 5 DESC, 1,2;
Essa consulta não se usa mais porque ela faz aproximações que não são
mais necessárias nem precisas. Use uma das que encontras aqui e nos
mande o resultado.
https://wiki.postgresql.org/wiki/Index_Maintenance
[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] auto relacionamento
2014-06-20 13:49 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com: O comando VACUUM FULL não diminui tamanho de índices, mas te tabelas. Para diminuir tamanho de índices usa-se o REINDEX. Só uma correção. Nas versões mais recentes (a partir da 9.0, se não me engano), o VACUUM FULL (VF) não precisa ser precedido de REINDEX, o próprio VF reescreve os índices também e diminui sim seus tamanhos. É verdade. Mas se eu tiver problemas de inchaço com um índice e não com a tabela, eu usaria REINDEX antes do VACUUM FULL. Ah sim. Eu só quis complementar a informação. Já nas versões anteriores, ele é praticamente requirido, já que antes o VF piorava a fragmentação. Mas eu diria para nem usar VF em versões Inchaço, correto? Sim. Também pode gerar problemas de fragmentação, mas inchaço era mesmo o termo que eu buscava sim. anteriores, basicamente nunca. E até nas mais recentes, apenas quando Existe o comando CLUSTER que faz mais ou menos o que a versão mais moderna do VACUUM FULL faz, com o adicional de ordenar a tabela por um índice. Exato. realmente comprovada a necessidade, muitas tabelas que sofrem muita atualização pode se beneficiar de um espacinho a mais, talvez até mesmo seja uma vantagem aumentar o fillfactor. Aí a discussão vai longe. Concordo, não é uma regra, é uma decisão à base de muita análise... Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] auto relacionamento
2014-06-20 13:58 GMT-03:00 Flavio Henrique Araque Gurgel fha...@gmail.com: Após o VACUUM FULL na versão 8.4 é melhor fazer um REINDEX. s/melhor/imprescindível/ Aliás, mantenha o autovacuum corretamente *ligado* e nunca mais faça VACUUMs FULLs. +1000 -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Auto Relacionamento
Jocemar Ferreira Garcia wrote: 2009/5/11 Euler Taveira de Oliveira eu...@timbira.com Jocemar Ferreira Garcia escreveu: Boa tarde a todos!! Estou modelando o controle financeiro do software da empresa onde trabalho e caí na seguinte questão: numa determinada ocasião, uma conta (caso seja paga parcialmente) deve ser baixada e do salvo devedor deve ser gerada uma outra conta. Como devo proceder? Como relacionar essas duas contas? Seria um relacionamento de conta com ela mesma? Qual a maneira correta e funcional de se implementar tao situação? Sem saber como está o seu modelo e os requisitos fica complicado sugerir algo. Mas o último sistema financeiro que modelei eu tinha as tabelas: contas e pagamentos. Uma conta tem 1 ou mais pagamentos; assim, eu consigo saber se ela foi paga parcialmente ou integralmente. Utilizei gatilhos para manter um estado (pago, parcialmente, não pago) na tabela contas (isso facilita a obtenção de contas por estado). A geração de uma outra conta só dificultaria o modelo. Mas é como eu disse: *não* posso supor nada porque não conheço os seus requisitos. Eu pensei numa implementação como essa... mas o detalhe é o seguinte: emite-se uma nota fiscal e dessa nota fiscal, gera-se um lançamento de uma conta a receber... o cliente paga essa conta com um cheque de metade do valor... convencionou-se então, que essa conta seria baixada e lançada então uma outra conta, com o valor restante... essa conta teria algo do tipo idContaPai... mas pensando em normalização, a historia de auto-relacionamento deve ser uma baita gambiarra ne... -- Euler Taveira de Oliveira http://www.timbira.com/ ___ 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 Eu já fiz um sistema gerando um novo registro com o valor remanescente na mesma tabela, e ja fiz com uma tabela filha (baixas). O primeiro modelo foi um tiro no pé. Deu muito trabalho pra fazer relatorios, por exemplo. Por exemplo, fazer um estorno, vc tem que ficar varrendo a thread de parcelas, e por ai vai. -- View this message in context: http://www.nabble.com/Auto-Relacionamento-tp23488704p23500467.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Auto Relacionamento
Euler, várias das idéias acima são boas... vou te passar uma que tive que implementar uma vez num cliente: As contas de alguns fornecedores eram pagas com cheques de terceiros... por esse motivo o valor dos cheques separados p/ o pagamento da conta dificilmente batiam com o valor a ser pago. Para controlar, tinhamos um conta corrente do fornecedor, e esse saldo do fornecedor, que poderia ser positivo ou negativo, era considerado a cada separação de cheques... Esse era caso meio especial mas funcionava 100%!!! Adriano 2009/5/12 Jean Domingues ejdom...@yahoo.com.br: Jocemar Ferreira Garcia wrote: 2009/5/11 Euler Taveira de Oliveira eu...@timbira.com Jocemar Ferreira Garcia escreveu: Boa tarde a todos!! Estou modelando o controle financeiro do software da empresa onde trabalho e caí na seguinte questão: numa determinada ocasião, uma conta (caso seja paga parcialmente) deve ser baixada e do salvo devedor deve ser gerada uma outra conta. Como devo proceder? Como relacionar essas duas contas? Seria um relacionamento de conta com ela mesma? Qual a maneira correta e funcional de se implementar tao situação? Sem saber como está o seu modelo e os requisitos fica complicado sugerir algo. Mas o último sistema financeiro que modelei eu tinha as tabelas: contas e pagamentos. Uma conta tem 1 ou mais pagamentos; assim, eu consigo saber se ela foi paga parcialmente ou integralmente. Utilizei gatilhos para manter um estado (pago, parcialmente, não pago) na tabela contas (isso facilita a obtenção de contas por estado). A geração de uma outra conta só dificultaria o modelo. Mas é como eu disse: *não* posso supor nada porque não conheço os seus requisitos. Eu pensei numa implementação como essa... mas o detalhe é o seguinte: emite-se uma nota fiscal e dessa nota fiscal, gera-se um lançamento de uma conta a receber... o cliente paga essa conta com um cheque de metade do valor... convencionou-se então, que essa conta seria baixada e lançada então uma outra conta, com o valor restante... essa conta teria algo do tipo idContaPai... mas pensando em normalização, a historia de auto-relacionamento deve ser uma baita gambiarra ne... -- Euler Taveira de Oliveira http://www.timbira.com/ ___ 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 Eu já fiz um sistema gerando um novo registro com o valor remanescente na mesma tabela, e ja fiz com uma tabela filha (baixas). O primeiro modelo foi um tiro no pé. Deu muito trabalho pra fazer relatorios, por exemplo. Por exemplo, fazer um estorno, vc tem que ficar varrendo a thread de parcelas, e por ai vai. -- View this message in context: http://www.nabble.com/Auto-Relacionamento-tp23488704p23500467.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. ___ 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
Re: [pgbr-geral] Auto Relacionamento
2009/5/12 Jean Domingues ejdom...@yahoo.com.br Eu já fiz um sistema gerando um novo registro com o valor remanescente na mesma tabela, e ja fiz com uma tabela filha (baixas). O primeiro modelo foi um tiro no pé. Deu muito trabalho pra fazer relatorios, por exemplo. Por exemplo, fazer um estorno, vc tem que ficar varrendo a thread de parcelas, e por ai vai. Não entendi a dificuldade em se ter a tabela pai e as tabelas filhas, principalmente se utilizar um identificador da tabela pai. Espeficamente sobre este caso, que foi aberto a tread, pode ser quando se trabalha com emissão de boletos. Aqui no escritorio no ERP (RM), eles te uma tabela para fazer estes vinculos, mas não usa um auto relacionamento. Acredito que para se ter um auto relacionamento, teria que fazer como um amigo aqui já sugeriu, se ter mais entidades vinculadas a pai. O Anderson mencionou sobre algo muito interessante, mas com relação a baixa não é problema, o maior problema fica entorno da tabela pai mesmo, principalmente se você tem duplicatas. -- []s Nilson Chagas - Ubuntu User 25794 --- Visite: http://www.amados.com.br/podcast - Peça gratuitamente um curso Bíblico http://tempodesalvacao.blogspot.com/ http://bbnradio.org/ - Ouça a rádio e faça gratuitamente um Curso Biblico ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Auto Relacionamento
crie um campo saldo devedor na mesma tabela e verifique se esta vazio 2009/5/11 Jocemar Ferreira Garcia jocema...@yahoo.com.br Boa tarde a todos!! Estou modelando o controle financeiro do software da empresa onde trabalho e caí na seguinte questão: numa determinada ocasião, uma conta (caso seja paga parcialmente) deve ser baixada e do salvo devedor deve ser gerada uma outra conta. Como devo proceder? Como relacionar essas duas contas? Seria um relacionamento de conta com ela mesma? Qual a maneira correta e funcional de se implementar tao situação? ___ 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
Re: [pgbr-geral] Auto Relacionamento
2009/5/11 Euler Taveira de Oliveira eu...@timbira.com Jocemar Ferreira Garcia escreveu: Boa tarde a todos!! Estou modelando o controle financeiro do software da empresa onde trabalho e caí na seguinte questão: numa determinada ocasião, uma conta (caso seja paga parcialmente) deve ser baixada e do salvo devedor deve ser gerada uma outra conta. Como devo proceder? Como relacionar essas duas contas? Seria um relacionamento de conta com ela mesma? Qual a maneira correta e funcional de se implementar tao situação? Sem saber como está o seu modelo e os requisitos fica complicado sugerir algo. Mas o último sistema financeiro que modelei eu tinha as tabelas: contas e pagamentos. Uma conta tem 1 ou mais pagamentos; assim, eu consigo saber se ela foi paga parcialmente ou integralmente. Utilizei gatilhos para manter um estado (pago, parcialmente, não pago) na tabela contas (isso facilita a obtenção de contas por estado). A geração de uma outra conta só dificultaria o modelo. Mas é como eu disse: *não* posso supor nada porque não conheço os seus requisitos. Eu pensei numa implementação como essa... mas o detalhe é o seguinte: emite-se uma nota fiscal e dessa nota fiscal, gera-se um lançamento de uma conta a receber... o cliente paga essa conta com um cheque de metade do valor... convencionou-se então, que essa conta seria baixada e lançada então uma outra conta, com o valor restante... essa conta teria algo do tipo idContaPai... mas pensando em normalização, a historia de auto-relacionamento deve ser uma baita gambiarra ne... -- Euler Taveira de Oliveira http://www.timbira.com/ ___ 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
Re: [pgbr-geral] Auto Relacionamento
2009/5/11 Jocemar Ferreira Garcia jocema...@yahoo.com.br Boa tarde a todos!! Estou modelando o controle financeiro do software da empresa onde trabalho e caí na seguinte questão: numa determinada ocasião, uma conta (caso seja paga parcialmente) deve ser baixada e do salvo devedor deve ser gerada uma outra conta. Como devo proceder? Como relacionar essas duas contas? Seria um relacionamento de conta com ela mesma? Qual a maneira correta e funcional de se implementar tao situação? voce ja pensou em criar uma, entidade para gravar os titulos, e outra para gravar as parcelas? caso for necessario a geração de bordero de cobrança para os titulos, vc devera criar mais entidades... (foi so uma ideia, posso estar enganado...) -- Lucas de Souza D'Ávila Graduando em Sistema de Informação - CV Lattes: http://lattes.cnpq.br/9245658982061645 http://merendas.blogspot.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Auto-relacionamento
pessoal estou com uma duvida.. eu gostaria de fazer um auto-relacionamento de uma tabela de contas que eu tenho a ddl da tabela é a seguinte: CREATE TABLE sh1.tplano_contas ( id_conta SERIAL, conta_pai INTEGER, codigo VARCHAR(20), descricao VARCHAR(70) NOT NULL, CONSTRAINT tplano_contas_pk PRIMARY KEY(id_conta), CONSTRAINT tplano_contas_fk FOREIGN KEY (conta_pai) REFERENCES sh1.tplano_contas(id_conta) ON DELETE NO ACTION ON UPDATE NO ACTION NOT DEFERRABLE ) WITHOUT OIDS; tenho os seguintes dados id_conta | conta_pai | codigo | descricao 1 | null | 1 | conta1 2 | 1 |1.1| conta1.1 3 | 2 | 1.1.1| conta1.1.1 4 | null | 2| conta2 e quando eu selecionar o código 1, eu gostaria de retornar todos os registros da conta 1. por exemplo: o id 1,2 e 3. estou tentando fazer o seguinte, mas não só retorna o registo 1: select plan_0.codigo from sh1.tplano_contas plan_0 , sh1.tplano_contas plan_1 where plan_0.id_conta = plan_1.conta_pai and plan_pai.id_conta = 1 order by plan_0.codigo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Auto-relacionamento
2007/9/4, Pedro B. Alves [EMAIL PROTECTED]: eu gostaria de fazer um auto-relacionamento de uma tabela de contas que eu tenho CONNECT BY do contrib. -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 5686 9607 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Auto-relacionamento
Leandro DUTRA wrote: eu gostaria de fazer um auto-relacionamento de uma tabela de contas que eu tenho CONNECT BY do contrib. O CONNECT BY [1] *não* está no contrib. O módulo do contrib se chama tablefunc que tem uma função connectby() que simula o que o Pedro quer. Possivelmente na versão 8.4 teremos a cláusula WITH (recursividade) implementada nativamente no PostgreSQL. [1] http://gppl.terminal.ru/ (parece que o site está off ou não existe mais; o patch está nos arquivos da lista do PostgreSQL). -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Auto-relacionamento
Pedro B. Alves wrote: se alguém tiver poderia simular pois estou precisando muito. obrigado. Como assim simular? O tablefunc basta que se instale o módulo. O patch do CONNECT BY é outra história... -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Auto-relacionamento
select p.* from sh1.tplano_contas p , (SELECT keyid, parent_keyid FROM connectby(sh1.tplano_contas', 'id_conta', 'conta_pai', '1', '1', 0) AS t(keyid text, parent_keyid text, level int, pos int)) as c where p.id_conta = c.keyid and p.conta_pai = c.parent_keyid consegui chegar até aqui... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
