Re: [pgbr-geral] Função Update or Insert
Em 10 de outubro de 2011 16:10, Fabrízio de Royes Mello fabriziome...@gmail.com escreveu: Todavia, melhor resolver mesmo na sua aplicação. Na minha visão, tentar fazer UPDATE numa linha que não existe tem mesmo é que retornar erro. +1 (mas sei que cada caso é um caso) Mas um UPDATE de uma linha que não existe não dá erro, apenas não faz nada pois não encontra nenhuma tupla que satisfaça a cláusula WHERE. No máximo retorna NOT FOUND numa procedure, mas não chega a dar erro. -- Atenciosamente, Alexsander da Rosa http://rednaxel.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] [DUVIDA] DBI-Link
On 12-10-2011 23:51, Luís Eduardo Porte wrote: Já efetuei outros testes de conexão do servidor e consigo.. não há bloqueios não. O que diz o log do FreeTDS? Já fizeste um programa em Perl utilizando DBI para verificar se o problema é no DBI-link? -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Configurando Timezones por databases
Pessoal, com a chegada do horário de verão, estou com um probleminha para resolver. Aqui na empresa, possuímos diversos databases de vários sistemas espalhados pelo Brasil inteiro, em um único servidor. Com o horário de verão chegando, não é possível simplesmente alterar o parâmetro no postgres.conf pois diversos estados não irão aderir ao horário de verão. O parâmetro de timezone no meu postgres.conf está como 'unknown'. Isso quer dizer que ele sincroniza com a variável de ambiente de TZ do Linux, correto? Quando bater o horário de verão, o meu servidor vai ajustar a hora automaticamente, e todas as bases devem ficar no horário de verão ( 1 hora adiantado). Para resolver o problema, pensei em dar um ALTER DATABASE database SET TIMEZONE TO 'Brazil/West', (offset -4) nos estados que não adotam o horário de verão, atrasando em 1 hora estas bases. O problema é que se eu altero o timezone da base, TODAS as datas da base, mesmo as anteriores ao horário de verão, vão ser alteradas no output. Como evitar isso? Talvez o a coluna is_dst em pg_timezone_names ajude em algo? Não entendi direito como ela funciona... Dados úteis: Versão do postgres: 8.4 Timezone atual de todas as bases: 'Brazil/East' Desde já, agradeço! -- Pedro Ivo Bispo de França ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Em 13 de outubro de 2011 10:47, Pedro Ivo Bispo França pe...@xbrain.com.brescreveu: Pessoal, com a chegada do horário de verão, estou com um probleminha para resolver. Aqui na empresa, possuímos diversos databases de vários sistemas espalhados pelo Brasil inteiro, em um único servidor. Com o horário de verão chegando, não é possível simplesmente alterar o parâmetro no postgres.conf pois diversos estados não irão aderir ao horário de verão. O parâmetro de timezone no meu postgres.conf está como 'unknown'. Isso quer dizer que ele sincroniza com a variável de ambiente de TZ do Linux, correto? Quando bater o horário de verão, o meu servidor vai ajustar a hora automaticamente, e todas as bases devem ficar no horário de verão ( 1 hora adiantado). Para resolver o problema, pensei em dar um ALTER DATABASE database SET TIMEZONE TO 'Brazil/West', (offset -4) nos estados que não adotam o horário de verão, atrasando em 1 hora estas bases. O problema é que se eu altero o timezone da base, TODAS as datas da base, mesmo as anteriores ao horário de verão, vão ser alteradas no output. Como evitar isso? Talvez o a coluna is_dst em pg_timezone_names ajude em algo? Não entendi direito como ela funciona... Dados úteis: Versão do postgres: 8.4 Timezone atual de todas as bases: 'Brazil/East' Bom dia Pedro, Ja tive muitos problemas com relação a horário de verão, a melhor solução que encontrei até hoje foi trabalhar com as bases de dados sempre em utc e deixar a aplicação fazer o cast para o timezone do estado especifico. []'s Edson Souza ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Obrigado pela resposta Edson! Queria deixar essa solução em último caso... Vamos torcer que alguém venha com alguma ideia genial... []'s Em 13 de outubro de 2011 10:58, Edson neto edson.edsn...@gmail.comescreveu: Em 13 de outubro de 2011 10:47, Pedro Ivo Bispo França pe...@xbrain.com.br escreveu: Pessoal, com a chegada do horário de verão, estou com um probleminha para resolver. Aqui na empresa, possuímos diversos databases de vários sistemas espalhados pelo Brasil inteiro, em um único servidor. Com o horário de verão chegando, não é possível simplesmente alterar o parâmetro no postgres.conf pois diversos estados não irão aderir ao horário de verão. O parâmetro de timezone no meu postgres.conf está como 'unknown'. Isso quer dizer que ele sincroniza com a variável de ambiente de TZ do Linux, correto? Quando bater o horário de verão, o meu servidor vai ajustar a hora automaticamente, e todas as bases devem ficar no horário de verão ( 1 hora adiantado). Para resolver o problema, pensei em dar um ALTER DATABASE database SET TIMEZONE TO 'Brazil/West', (offset -4) nos estados que não adotam o horário de verão, atrasando em 1 hora estas bases. O problema é que se eu altero o timezone da base, TODAS as datas da base, mesmo as anteriores ao horário de verão, vão ser alteradas no output. Como evitar isso? Talvez o a coluna is_dst em pg_timezone_names ajude em algo? Não entendi direito como ela funciona... Dados úteis: Versão do postgres: 8.4 Timezone atual de todas as bases: 'Brazil/East' Bom dia Pedro, Ja tive muitos problemas com relação a horário de verão, a melhor solução que encontrei até hoje foi trabalhar com as bases de dados sempre em utc e deixar a aplicação fazer o cast para o timezone do estado especifico. []'s Edson Souza ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Pedro Ivo Bispo de França X-Brain - Desenvolvimento de Sistemas Ltda Contato: +55 43 3304-2204 | +55 43 9608-3678 Avenida Tiradentes, 501 Sala 702 Torre 1 - Jd. Shangrilá Londrina - Paraná - 86070-545 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Duvidas com Right Outer Join
Pessoal mais uma vez preciso da vossa ajuda
Tenho o seguinte select
select distinct f.data_age, a.cod_key, a.cod_id, d.nome, d.end_abr, d.end_cad,
d.end_num, d.end_com, d.end_bai, d.end_cid, d.end_est, end_cep, a.pedido,
a.data_age, a.hora_age, a.hora_fim, a.codigo, b.descricao, c.qtd_item,
e.obs_tecnico, a.tipo, a.agendamento, a.cod_ope, a.data_cad, a.obs,
a.observacoes, a.obs_interna
from mv_vendas_pre_agenda a
inner join mv_produtos b on(b.codigo = a.codigo)
inner join mv_vendas_pre_itens c on(c.cod_id = a.cod_id)
and(c.pedido = a.pedido)
and(c.codigo = a.codigo)
and(c.obs not in('C'))
left join mv_vendas e on(e.cod_id = a.cod_id)
and(e.pedido = a.pedido)
inner join mv_clientes d on(d.cod_id = a.cod_id)
right join mv_vendas_pre_mes f on(f.data_age = a.data_age)
where (a.obs not in('C'))
and(b.tipo = 'M')
and((a.data_age is null)or(a.data_age = '01/10/2011'))
order by a.data_age, a.hora_age, a.cod_id
Desculpe colocar o select todo, mas acho que fica melhor a compreensão
A ideia é que a tabelas mv_vendas_pre_mes ( F ) tem registros que não tem na
tabela ( A )
Mas preciso trazer essas datas justamente pra mostrar que não existem
agendamentos naquele dia.
Imagino que o Right Join deveria trazer todos os registros da tabela ( F )
mesmo não contendo a referncia, mas não é isso que ocorre.
Não estou compreendendo esse Right
Eu preciso que a tabela ( A ) seja a tabela principal do select
Agradeço todas as dica
Marcelo Silva
--
Desenvolvedor Delphi, PHP
msn: marc...@ig.com.br
cel.: (11) 9693-4251wlEmoticon-smile[1].png___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
2011/10/13 Pedro Ivo Bispo França pe...@xbrain.com.br: Aqui na empresa, possuímos diversos databases de vários sistemas espalhados pelo Brasil inteiro, em um único servidor. Com o horário de verão chegando, não é possível simplesmente alterar o parâmetro no postgres.conf pois diversos estados não irão aderir ao horário de verão. Rapaz, tinha de ter pensado isso na criação da base e do aplicativo. O certo é deixar o servidor configurado corretamente, com o relógio de máquina em UTC e o SO configurado na cidade de referência correta para fuso e horário de verão. Todos os atributos temporais têm de ser declarados WITH TIMEZONE, para também irem para UTC mais ou menos fuso e horário de verão. Então, a aplicação e usuários sempre lidarão com o tempo dando a informação de hora local e fuso, ou UTC. Só assim a base ficará realmente consistente. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/13 Alexsander Rosa alexsander.r...@gmail.com: Mas um UPDATE de uma linha que não existe não dá erro, apenas não faz nada pois não encontra nenhuma tupla que satisfaça a cláusula WHERE. No máximo retorna NOT FOUND numa procedure, mas não chega a dar erro. Pois é, e o código tem de capturar o NOT FOUND como qualquer outro erro, e tratá-lo, seja abortando, convertendo num INSERT ou seja lá o que fôr correto no caso. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 13 de outubro de 2011 11:49, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2011/10/13 Alexsander Rosa alexsander.r...@gmail.com: Mas um UPDATE de uma linha que não existe não dá erro, apenas não faz nada pois não encontra nenhuma tupla que satisfaça a cláusula WHERE. No máximo retorna NOT FOUND numa procedure, mas não chega a dar erro. Pois é, e o código tem de capturar o NOT FOUND como qualquer outro erro, e tratá-lo, seja abortando, convertendo num INSERT ou seja lá o que fôr correto no caso. Sintaxe do MERGE: MERGE INTO table_name USING table_reference ON (condition) WHEN MATCHED THEN UPDATE SET column1 = value1 [, column2 = value2 ...] WHEN NOT MATCHED THEN INSERT (column1 [, column2 ...]) VALUES (value1 [, value2 ... Fonte: http://en.wikipedia.org/wiki/Merge_%28SQL%29 -- Atenciosamente, Alexsander da Rosa http://rednaxel.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] Função Update or Insert
Em 12-10-2011 21:48, Tiago Adami escreveu: Ok, entendi. Mas isto só se aplica quando você está usando SEQUENCES em chaves primárias - possivelmente artificiais. Isto não funcionaria com chaves naturais, do tipo CHAR ou VARCHAR, por exemplo. Agora começo entender porque os arquitetos de software vivem reclamando quando recuso a criação de chaves artificiais (geralmente colunas com nome ID do tipo Integer) só porque fica mais fácil trabalhar com Hibernate :) Exato, para ter algo gerado automaticamente obviamente ele deveria seguir um padrão onde o banco de dados pudesse gerar por si só este valor. Caso contrário, não tem nem lógica enviar um insert para o servidor sem a chave primária. ORM não resolve todos os males do mundo, ele resolve a grande maioria deles, mas não todos. Para mim, insert, update e delete é 99% por conta do ORM porque é quase sempre a mesma coisa. -- Shander Lyrio http://about.com/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 12-10-2011 22:10, Guimarães Faria Corcete DUTRA, Leandro escreveu: começo entender porque os arquitetos de software vivem reclamando quando recuso a criação de chaves artificiais (geralmente colunas com nome ID do tipo Integer) só porque fica mais fácil trabalhar com Hibernate :) Espero que eles entendam que é porque chave artificial não garante unicidade, e geralmente confiar nelas deixa a base de dados inconsistente. Examente por isto você pode sempre criar um índice unique na chave natural que você usaria e que acha que garante unicidade. Teria o mesmo efeito de garantir unicidade, e ainda facilitaria o uso do ORM. A que custo?? Um pouco mais de espaço utilizado em disco. Eu acredito que o meio termo é, quase sempre, a melhor saída. Já vi diversas discursões sobre isto aqui na lista e no final sempre chega-se a conclusão que encontrar uma chave natural que realmente seja única é tão difícil quando encontrar um gnomo no final do arco-íres. -- Shander Lyrio http://about.com/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 13-10-2011 11:49, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/13 Alexsander Rosaalexsander.r...@gmail.com: Mas um UPDATE de uma linha que não existe não dá erro, apenas não faz nada pois não encontra nenhuma tupla que satisfaça a cláusula WHERE. No máximo retorna NOT FOUND numa procedure, mas não chega a dar erro. Pois é, e o código tem de capturar o NOT FOUND como qualquer outro erro, e tratá-lo, seja abortando, convertendo num INSERT ou seja lá o que fôr correto no caso. Mas aí você não se contraria quando disse que era melhor fazer tudo em uma única consulta? Desta forma ele faria sempre em duas, então quer dizer que com o ORM tudo seria mais eficiente, no mínimo igual. Né não? Eu já havia feito estas contas, mas não havia pensando na possibilidade de tratamento do notfound, mesmo assim o ORM é ainda é mais econômico. Gostei! Abraço, -- Shander Lyrio http://about.com/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
On 13-10-2011 10:47, Pedro Ivo Bispo França wrote: O problema é que se eu altero o timezone da base, TODAS as datas da base, mesmo as anteriores ao horário de verão, vão ser alteradas no output. Como evitar isso? Talvez o a coluna is_dst em pg_timezone_names ajude em algo? Não entendi direito como ela funciona... Isso porque você *não* armazena o timezone no campo data/hora (aka timestamp without time zone). Quando estamos trabalhando com data/hora temos que fazer a seguinte pergunta: a zona horária de armazenamento é a mesma que a de apresentação? Se sim, podemos utilizar o tipo de dado 'timestamp without time zone'; senão, o tipo de dado deve ser 'timestamp with time zone'. A coluna is_dst indica se a zona horária possui horário de verão ou não (aka daylight saving time). Aplicações que funcionam em múltiplas zonas horárias geralmente escolhem uma zona horária padrão (por exemplo, horário de Brasília), utilizam o tipo de dado 'timestamp with time zone' e ao manipular os campos data/hora sempre utilizam AT TIMEZONE 'foo' [1] de acordo com cada caso. [1] http://www.postgresql.org/docs/current/static/functions-datetime.html#FUNCTIONS-DATETIME-ZONECONVERT -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Euler, mas eu armazeno a data em um timestamp with time zone, porém, ele não armazena o timezone no momento da gravação, a hora armazenada é a equivalente em UTC, e no momento do display, ele faz o ajuste dependendo da timezone atual. Confere? Não vejo um jeito de adaptar isso tudo e deixar os dados consistentes. Se eu pudesse, falaria para todo mundo seguir um horário só e pronto, mas ajustar o relógio corretamente com a do estado é uma demanda do cliente. Ainda estou analisando que rumo tomar... Obrigado pelas colaborações gente Em 13 de outubro de 2011 13:03, Euler Taveira de Oliveira eu...@timbira.com escreveu: On 13-10-2011 10:47, Pedro Ivo Bispo França wrote: O problema é que se eu altero o timezone da base, TODAS as datas da base, mesmo as anteriores ao horário de verão, vão ser alteradas no output. Como evitar isso? Talvez o a coluna is_dst em pg_timezone_names ajude em algo? Não entendi direito como ela funciona... Isso porque você *não* armazena o timezone no campo data/hora (aka timestamp without time zone). Quando estamos trabalhando com data/hora temos que fazer a seguinte pergunta: a zona horária de armazenamento é a mesma que a de apresentação? Se sim, podemos utilizar o tipo de dado 'timestamp without time zone'; senão, o tipo de dado deve ser 'timestamp with time zone'. A coluna is_dst indica se a zona horária possui horário de verão ou não (aka daylight saving time). Aplicações que funcionam em múltiplas zonas horárias geralmente escolhem uma zona horária padrão (por exemplo, horário de Brasília), utilizam o tipo de dado 'timestamp with time zone' e ao manipular os campos data/hora sempre utilizam AT TIMEZONE 'foo' [1] de acordo com cada caso. [1] http://www.postgresql.org/docs/current/static/functions-datetime.html#FUNCTIONS-DATETIME-ZONECONVERT -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Pedro Ivo Bispo de França X-Brain - Desenvolvimento de Sistemas Ltda Contato: +55 43 3304-2204 | +55 43 9608-3678 Avenida Tiradentes, 501 Sala 702 Torre 1 - Jd. Shangrilá Londrina - Paraná - 86070-545 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
2011/10/13 Pedro Ivo Bispo França pe...@xbrain.com.br: Euler, mas eu armazeno a data em um timestamp with time zone, porém, ele não armazena o timezone no momento da gravação, a hora armazenada é a equivalente em UTC, e no momento do display, ele faz o ajuste dependendo da timezone atual. Confere? Não vejo um jeito de adaptar isso tudo e deixar os dados consistentes. Mas é isso mesmo, e assim que tem de ser. A consistência está no armazenamento em UTC. Se eu pudesse, falaria para todo mundo seguir um horário só e pronto, mas ajustar o relógio corretamente com a do estado é uma demanda do cliente. Ainda estou analisando que rumo tomar... Isso é uma configuração do cliente, a qual a aplicação tem de ler para trabalhar corretamente. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/13 Shander Lyrio shan...@nucleo45.com.br: Examente por isto você pode sempre criar um índice unique na chave natural que você usaria e que acha que garante unicidade. Teria o mesmo efeito de garantir unicidade, e ainda facilitaria o uso do ORM. A que custo?? Um pouco mais de espaço utilizado em disco. Há outros custos. O cache fica mais sujo mais rápido, o modelo de dados fica mais opaco, a tentação de usar a chave artificial para todas as chaves estrangeiras aumenta e acaba‐se sendo forçado a fazer junções que seriam desnecessárias se as chaves estrangeiras fossem sobre as naturais. Sem contar que chaves naturais têm o potencial de satisfazer consultas com o índice implícito, sem precisar nem ir para a tabela; se a aplicação já usa as chaves naturais preferencialmente, isso tenderá a estar em memória também, com ganhos ainda melhores. Eu acredito que o meio termo é, quase sempre, a melhor saída. Já vi diversas discursões sobre isto aqui na lista e no final sempre chega-se a conclusão que encontrar uma chave natural que realmente seja única é tão difícil quando encontrar um gnomo no final do arco-íres. Não é verdade. Quem chega a essa conclusão é quem não entendeu o modelo de dados, e aí a modelagem e aplicação serão malfeitas, com as conseqüências de sempre para desempenho, documentação, consistência… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/13 Shander Lyrio shan...@nucleo45.com.br: Em 13-10-2011 11:49, Guimarães Faria Corcete DUTRA, Leandro escreveu: Pois é, e o código tem de capturar o NOT FOUND como qualquer outro erro, e tratá-lo, seja abortando, convertendo num INSERT ou seja lá o que fôr correto no caso. Mas aí você não se contraria quando disse que era melhor fazer tudo em uma única consulta? Eu? Eu falei que não era para fazer consulta nenhuma, só executar a operação que se espera a mais comum primeiro, capturar eventuais erros (inclusive tupla não encontrada num caso, preexistente noutro) e então decidir se executa a outra. Desta forma ele faria sempre em duas Pelo contrário. Geralmente faz‐se apenas uma operação, em vez de obrigatoriamente uma consulta e mais uma operação. quer dizer que com o ORM tudo seria mais eficiente, no mínimo igual. Não. Porque ele afasta o desenvolvedor do SQL, impondo uma mentalidade imperativa em vez da declarativa nativa; e porque ele tem o estado da base replicado na aplicação, impondo custos adicionais. Eu já havia feito estas contas, mas não havia pensando na possibilidade de tratamento do notfound, mesmo assim o ORM é ainda é mais econômico. Isso seria absolutamente impossível. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/13 Shander Lyrio shan...@nucleo45.com.br: Exato, para ter algo gerado automaticamente obviamente ele deveria seguir um padrão onde o banco de dados pudesse gerar por si só este valor. Caso contrário, não tem nem lógica enviar um insert para o servidor sem a chave primária. Se a inserção não tem chave candidata natural, a tabela é um saco, não uma relação. Se a chave candidata natural é a primária ou não, só vai fazer diferença de acordo com o contexto, não inerentemente. ORM não resolve todos os males do mundo, ele resolve a grande maioria deles, mas não todos. Para mim, insert, update e delete é 99% por conta do ORM porque é quase sempre a mesma coisa. Non sequitur. De qualquer maneira, ORM cria mais problemas que resolve. O problema é menos grave com ORMs relativamente bons como o SQL Alchemy, e mais com nojentos como o Hibernate, mas sempre existe. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
entendi... Estou pensando em por uma flag no banco, que diz se o estado participa ou não do horário de verão. A aplicação, ao abrir a sessão le esse parâmetro, e da um AT TIMEZONE correspondente, se a data estiver nos períodos de horário de verão. O que acham? Se tiverem uma idéia melhor, podem sugerir []'s Em 13 de outubro de 2011 13:37, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2011/10/13 Pedro Ivo Bispo França pe...@xbrain.com.br: Euler, mas eu armazeno a data em um timestamp with time zone, porém, ele não armazena o timezone no momento da gravação, a hora armazenada é a equivalente em UTC, e no momento do display, ele faz o ajuste dependendo da timezone atual. Confere? Não vejo um jeito de adaptar isso tudo e deixar os dados consistentes. Mas é isso mesmo, e assim que tem de ser. A consistência está no armazenamento em UTC. Se eu pudesse, falaria para todo mundo seguir um horário só e pronto, mas ajustar o relógio corretamente com a do estado é uma demanda do cliente. Ainda estou analisando que rumo tomar... Isso é uma configuração do cliente, a qual a aplicação tem de ler para trabalhar corretamente. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Pedro Ivo Bispo de França X-Brain - Desenvolvimento de Sistemas Ltda Contato: +55 43 3304-2204 | +55 43 9608-3678 Avenida Tiradentes, 501 Sala 702 Torre 1 - Jd. Shangrilá Londrina - Paraná - 86070-545 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 13 de outubro de 2011 13:57, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2011/10/13 Shander Lyrio shan...@nucleo45.com.br: ORM não resolve todos os males do mundo, ele resolve a grande maioria deles, mas não todos. Para mim, insert, update e delete é 99% por conta do ORM porque é quase sempre a mesma coisa. Non sequitur. De qualquer maneira, ORM cria mais problemas que resolve. O problema é menos grave com ORMs relativamente bons como o SQL Alchemy, e mais com nojentos como o Hibernate, mas sempre existe. Na minha opinião um ORM só é útil em telas de cadastro extensas, onde fica mais fácil preencher as propriedades de um objeto e depois simplesmente executar um Save() e deixar o OPF se virar pra ver se vai usar INSERT ou UPDATE, ou ainda quais propriedades vai precisar alterar e quais pode omitir, etc. OK, o OPF provavelmente vai dar um SELECT * FROM tabela WHERE chave = x e pegar a tupla inteira, mas numa tela de cadastro isto é razoável -- se a chave não for obrigatoriamente um ID serial artificial, evidentemente. Ainda acho mais fácil fazer um cadastro de cliente desta maneira do que montar um SQL dinamicamente, por exemplo. No entanto é preciso ter cuidado e usar o OPF apenas nas telas de cadastro. Não dá pra usar o OPF numa tela que mostra uma LISTA de objetos buscados com SELECT *, isto gera um tráfego imenso e desnecessário. Nestes casos sempre é melhor usar uma VIEW que retorna apenas o que vai aparecer na tela -- aliás esta é uma regra aqui na Rednaxel: somente popule listas com views e somente coloque nas views dados que efetivamente aparecem na tela. De resto, damos preferência para stored procedures que fazem coisas como emite_nota, baixa_estoque, etc. Com isso as regras de negócio ficam no BD e podem ser acessadas por aplicações standalone, console, web, mobile, etc de forma transparente. -- Atenciosamente, Alexsander da Rosa http://rednaxel.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] Função Update or Insert
2011/10/13 Alexsander Rosa alexsander.r...@gmail.com: De resto, damos preferência para stored procedures que fazem coisas como emite_nota, baixa_estoque, etc. Com isso as regras de negócio ficam no BD e podem ser acessadas por aplicações standalone, console, web, mobile, etc de forma transparente. O dia que tivermos um sistema completo de restrições de integridade, incluindo o ASSERTION de que o Euler lembrou outro dia, chaves em visões c, não precisaremos de código procedural para termos as regras de negócio na base… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
2011/10/13 Pedro Ivo Bispo França pe...@xbrain.com.br: Estou pensando em por uma flag no banco, que diz se o estado participa ou não do horário de verão. A aplicação, ao abrir a sessão le esse parâmetro, e da um AT TIMEZONE correspondente, se a data estiver nos períodos de horário de verão. Na verdade, é um pouco mais simples. A base de dados de tempo, que já está disponível no SO, tem essa informação. Ela não consta por estado, porque poderia acontecer de um estado ter parte no horário de verão, parte fora ou, mais provavelmente, parte num fuso horário, parte noutro (por exemplo, Fernando de Noronha é parte de Pernambuco, e o oeste do Amazonas segue o Acre). Em vez disso, os fusos têm nomes, mas acaba‐se usando mais uma cidade de referência, como se vê na tabela 8‐12 na seção 8.5.1.2 do manual http://www.postgresql.org/docs/9.1/interactive/datatype-datetime.html. Portanto, basta recuperar essa informação do SO e informá‐la ao abrir a sessão do cliente, ou antes de começar uma transação, sem se preocupar com determinar em que fuso ou horário se está; a informação vira praticamente um biscoito mágico (/magic cookie/) que a aplicação busca no SO e passa para a base. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Nossa...muito obrigado!! Ajudou bastante!! Vou tentar resolver o problema desta forma! Obrigado a todos que contribuiram Em 13 de outubro de 2011 14:45, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2011/10/13 Pedro Ivo Bispo França pe...@xbrain.com.br: Estou pensando em por uma flag no banco, que diz se o estado participa ou não do horário de verão. A aplicação, ao abrir a sessão le esse parâmetro, e da um AT TIMEZONE correspondente, se a data estiver nos períodos de horário de verão. Na verdade, é um pouco mais simples. A base de dados de tempo, que já está disponível no SO, tem essa informação. Ela não consta por estado, porque poderia acontecer de um estado ter parte no horário de verão, parte fora ou, mais provavelmente, parte num fuso horário, parte noutro (por exemplo, Fernando de Noronha é parte de Pernambuco, e o oeste do Amazonas segue o Acre). Em vez disso, os fusos têm nomes, mas acaba‐se usando mais uma cidade de referência, como se vê na tabela 8‐12 na seção 8.5.1.2 do manual http://www.postgresql.org/docs/9.1/interactive/datatype-datetime.html. Portanto, basta recuperar essa informação do SO e informá‐la ao abrir a sessão do cliente, ou antes de começar uma transação, sem se preocupar com determinar em que fuso ou horário se está; a informação vira praticamente um biscoito mágico (/magic cookie/) que a aplicação busca no SO e passa para a base. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Pedro Ivo Bispo de França X-Brain - Desenvolvimento de Sistemas Ltda Contato: +55 43 3304-2204 | +55 43 9608-3678 Avenida Tiradentes, 501 Sala 702 Torre 1 - Jd. Shangrilá Londrina - Paraná - 86070-545 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 13-10-2011 13:48, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/13 Shander Lyrioshan...@nucleo45.com.br: Eu acredito que o meio termo é, quase sempre, a melhor saída. Já vi diversas discursões sobre isto aqui na lista e no final sempre chega-se a conclusão que encontrar uma chave natural que realmente seja única é tão difícil quando encontrar um gnomo no final do arco-íres. Não é verdade. Quem chega a essa conclusão é quem não entendeu o modelo de dados, e aí a modelagem e aplicação serão malfeitas, com as conseqüências de sempre para desempenho, documentação, consistência… Não, quem chega a esta conclusão é quem está vivendo o processo do desenvolvimento. Modelo relacional não explica tudo, tentar forçar tudo a se encaixar no modelo relacional é contraproducente. O que seria chave natural para um cadastro de clientes?? cpf se for física ou cnpj se for jurídica? existe alguma melhor? e quando a esposa e o marido usam o mesmo cpf ou cara é de fora do Brasil e seu documento chama-se passaporte? e quando várias empresas usarem o mesmo cnpj como é o caso de um colega do sul que presta serviço à escolas que se não me engano tem o mesmo cnpj? Isso já foi discutido aqui na lista diversas vezes. Estou quase convencido que não existe uma chave natural perfeita para este simples cadastro de clientes, que tal um sequenciamento genético? Hum não funcionaria em empresas!!! Sequenciamento genético com os donos?? A!!! E quando a empresa fosse S/A?? Poxa!!! Você já parou para pensar que quando algo vai para o cache do PostGreSql, a página de dados toda vai para o cache?? não são simplesmente os dados, mas toda a página, com todos os campos. Ela pode inclusive estar cheia de buracos de registros já apagados e atualizados que ainda não foram recuperados com um vacuum, um campo a mais indo para o cache vai impactar um pentelhésimo de segundo ou nada. Se estivermos falando do que está definido no effective_cache_size, o assunto é ainda mais complexo, porque apenas os campos selecionados vão para esta área da memória para as agregação, join, e etc. Pessoalmente acho que o melhor custo/benefício é trabalhar com o cache da aplicação, ele bem administrado vai reduzir drasticamente a quantidade de consultas enviadas para o banco de dados. Sempre tem um porém, sempre tem um más. Na prática a teoria é outra coisa! Ainda acho que o caminho é DBA e equipe de programação tentando trabalhar juntos, um tentando ajudar o outro no que for melhor para a aplicação e quando digo aplicação, digo sistema + banco de dados. Se eu economizo várias horas de programação da equipe eu tenho mais condições de barganhar um sistema de discos melhor, mais memória, mais processador. Sei que alguns colegas respondem como se fossem unicamente DBA's a conversar nesta lista, mas não são, tem caras, onde eu me encaixo, que estão apenas tentando tornar o gap que existe entre banco de dados e aplicação um pouquinho menor. Abraço, -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Duvidas com Right Outer Join
Em 13 de outubro de 2011 11:07, Marcelo Silva (IG) marc...@ig.com.br escreveu:
Pessoal mais uma vez preciso da vossa ajuda
Tenho o seguinte select
select distinct f.data_age, a.cod_key, a.cod_id, d.nome, d.end_abr,
d.end_cad, d.end_num, d.end_com, d.end_bai, d.end_cid, d.end_est, end_cep,
a.pedido, a.data_age, a.hora_age, a.hora_fim, a.codigo, b.descricao,
c.qtd_item, e.obs_tecnico, a.tipo, a.agendamento, a.cod_ope, a.data_cad,
a.obs, a.observacoes, a.obs_interna
from mv_vendas_pre_agenda a
inner join mv_produtos b on(b.codigo = a.codigo)
inner join mv_vendas_pre_itens c on(c.cod_id = a.cod_id)
and(c.pedido = a.pedido)
and(c.codigo = a.codigo)
and(c.obs not in('C'))
left join mv_vendas e on(e.cod_id = a.cod_id)
and(e.pedido = a.pedido)
inner join mv_clientes d on(d.cod_id = a.cod_id)
right join mv_vendas_pre_mes f on(f.data_age = a.data_age)
where (a.obs not in('C'))
and(b.tipo = 'M')
and((a.data_age is null)or(a.data_age = '01/10/2011'))
order by a.data_age, a.hora_age, a.cod_id
Desculpe colocar o select todo, mas acho que fica melhor a compreensão
A ideia é que a tabelas mv_vendas_pre_mes ( F ) tem registros que não tem na
tabela ( A )
Mas preciso trazer essas datas justamente pra mostrar que não existem
agendamentos naquele dia.
Imagino que o Right Join deveria trazer todos os registros da tabela ( F )
mesmo não contendo a referncia, mas não é isso que ocorre.
Não estou compreendendo esse Right
Eu preciso que a tabela ( A ) seja a tabela principal do select
Tente definir explicitamente, com o uso de parênteses a ordem de seus join.
Osvaldo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
2011/10/13 Shander Lyrio shan...@nucleo45.com.br: O problema ocorre quando vários clientes de fusos horários diferentes tem seu sistema hospedado em um mesmo servidor, o que não é incomum em SaaS. Se o sistema roda no servidor, isso é bom — mas, se isso significa que ele não se comunica com o cliente, isso é ruim. Nesse caso, a informação teria de ser prestada pelo usuário. Ainda tenho um caso mais complicado e neste precisei incluir um campo para cada usuário indicando em qual fuso horário ele se encontra. CQD acima. Imagina um sistema de logística onde gente do Brasil inteiro insere dados, cada um estando em um fuso horário diferente. Qual o problema? Na prática a teoria é outra coisa. Nada a ver. Teoria é explicação da realidade, só isso. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/13 Shander Lyrio shan...@nucleo45.com.br: Não, quem chega a esta conclusão é quem está vivendo o processo do desenvolvimento. Modelo relacional não explica tudo, tentar forçar tudo a se encaixar no modelo relacional é contraproducente. Modelo não é e nunca foi explicação, é formalização. Se não pode ser formalizado, será inconsistente. O que seria chave natural para um cadastro de clientes?? cpf se for física ou cnpj se for jurídica? existe alguma melhor? e quando a esposa e o marido usam o mesmo cpf ou cara é de fora do Brasil e seu documento chama-se passaporte? e quando várias empresas usarem o mesmo cnpj como é o caso de um colega do sul que presta serviço à escolas que se não me engano tem o mesmo cnpj? Isso já foi discutido aqui na lista diversas vezes. Sim, e a conclusão sempre foi a mesma: em última instância, a chave natural pode vir a ser a tabela toda, excluídos atributos artificiais. Se nem isso identificar, então a base de dados será inconsistente. Estou quase convencido que não existe uma chave natural perfeita para este simples cadastro de clientes, que tal um sequenciamento genético? Hum não funcionaria em empresas!!! Sequenciamento genético com os donos?? A!!! E quando a empresa fosse S/A?? Poxa!!! Quem perde a calma perde a razão. Você já parou para pensar que quando algo vai para o cache do PostGreSql, a página de dados toda vai para o cache?? Por favor, o nome do sistema é PostgreSQL ou Postgres. não são simplesmente os dados, mas toda a página, com todos os campos. Ela pode inclusive estar cheia de buracos de registros já apagados e atualizados que ainda não foram recuperados com um vacuum, um campo a mais indo para o cache vai impactar um pentelhésimo de segundo ou nada. Se estivermos falando do que está definido no effective_cache_size, o assunto é ainda mais complexo, porque apenas os campos selecionados vão para esta área da memória para as agregação, join, e etc. E daí? Pessoalmente acho que o melhor custo/benefício é trabalhar com o cache da aplicação, ele bem administrado vai reduzir drasticamente a quantidade de consultas enviadas para o banco de dados. O seu achômetro pessoal vai contra a experiência geral da humanidade. O cache da aplicação tem seu lugar, mas ele não está tão próximo do disco quanto o da base. Sempre tem um porém, sempre tem um más. Na prática a teoria é outra coisa! Ainda acho que o caminho é DBA e equipe de programação tentando trabalhar juntos, um tentando ajudar o outro no que for melhor para a aplicação e quando digo aplicação, digo sistema + banco de dados. E, para isso, quem tem a visão geral dos dados é o AD, que pode ou não ser o DBA. Se eu economizo várias horas de programação da equipe eu tenho mais condições de barganhar um sistema de discos melhor, mais memória, mais processador. O que não adianta nada quando a aplicação não escala e a base é inconsistente. Sei que alguns colegas respondem como se fossem unicamente DBA's a conversar nesta lista, mas não são, tem caras, onde eu me encaixo, que estão apenas tentando tornar o gap que existe entre banco de dados e aplicação um pouquinho menor. E esses caras fariam bem em tentar aprender um pouco em vez de sempre reagir emocionalmente. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Em 13/10/2011 15:39, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/13 Shander Lyrioshan...@nucleo45.com.br: O problema ocorre quando vários clientes de fusos horários diferentes tem seu sistema hospedado em um mesmo servidor, o que não é incomum em SaaS. Se o sistema roda no servidor, isso é bom — mas, se isso significa que ele não se comunica com o cliente, isso é ruim. Nesse caso, a informação teria de ser prestada pelo usuário. Ainda tenho um caso mais complicado e neste precisei incluir um campo para cada usuário indicando em qual fuso horário ele se encontra. CQD acima. Imagina um sistema de logística onde gente do Brasil inteiro insere dados, cada um estando em um fuso horário diferente. Qual o problema? Concordo, não vejo problema a não ser quando o mesmo usuário é usado em vários logins ao mesmo tempo e em diferentes lugares, fora isso acho que é bem fácil de resolver. Na prática a teoria é outra coisa. Nada a ver. Teoria é explicação da realidade, só isso. Desculpe-me, mas teoria é um ponto de vista de um mundo ideal e que sabemos fica bem longe do mundo real. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
2011/10/13 Flávio Alves Granato flavio.gran...@gmail.com: Em 13/10/2011 15:39, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/13 Shander Lyrioshan...@nucleo45.com.br: Imagina um sistema de logística onde gente do Brasil inteiro insere dados, cada um estando em um fuso horário diferente. Qual o problema? Concordo, não vejo problema a não ser quando o mesmo usuário é usado em vários logins ao mesmo tempo e em diferentes lugares, fora isso acho que é bem fácil de resolver. Nesse caso, a gente volta à solução ideal — o cliente tem de informar à aplicação onde está — e ao contorno — o usuário terá de informar toda vez que abrir uma sessão. Na prática a teoria é outra coisa. Nada a ver. Teoria é explicação da realidade, só isso. Desculpe-me, mas teoria é um ponto de vista de um mundo ideal e que sabemos fica bem longe do mundo real. Cada ponto de vista representa uma teoria. Quando não corresponder à realidade, busca‐se outra teoria que corresponda melhor. Ainda não arranjaram teoria melhor que o modelo relacional. É como Unix: quem não conhece, está sujeito a cometer os mesmo erros vez após vez. E hoje temos a lei de Moore para camuflar os problemas até que seja tarde demais para consertá‐los. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Em 13-10-2011 15:39, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/13 Shander Lyrioshan...@nucleo45.com.br: O problema ocorre quando vários clientes de fusos horários diferentes tem seu sistema hospedado em um mesmo servidor, o que não é incomum em SaaS. Se o sistema roda no servidor, isso é bom — mas, se isso significa que ele não se comunica com o cliente, isso é ruim. Nesse caso, a informação teria de ser prestada pelo usuário. O Sistema roda na Web, um browser não passa automaticamente o fuso horário numa requisição http, também não tem como você pedir para o browser te passar esta informação do sistema operacional do usuário por questões de segurança. Todo sistema cliente/servidor tem que se comunicar obviamente com o servidor, senão não seria necessário o segundo, o que é comunicado é a questão. Pela sua colocação então, todos os sistemas web que rodam em algum browser são ruins. Bom ou Ruim depende de contexto e a afirmação categórica de algum deles sem contexto é irrelevante. Imagina um sistema de logística onde gente do Brasil inteiro insere dados, cada um estando em um fuso horário diferente. Qual o problema? Seu CPD pode estar em São Paulo, importar os arquivos de carga do cliente, a coleta destes documentos serem descentralizadas e alguém em Pernambuco lançar a coleta deste documento uns minutos depois. No tracking você vai ver algo bizarro como a coleta ser realizada antes do arquivo ter sido processado pelo cliente. Na prática a teoria é outra coisa. Nada a ver. Teoria é explicação da realidade, só isso. Teoria é a tentativa de explicação da realidade pelos olhos de quem tentou dar esta explicação. Vista de apenas um ângulo é no mínimo limitada. -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Pessoalmente acho que o melhor custo/benefício é trabalhar com o cache da aplicação, ele bem administrado vai reduzir drasticamente a quantidade de consultas enviadas para o banco de dados. O seu achômetro pessoal vai contra a experiência geral da humanidade. O cache da aplicação tem seu lugar, mas ele não está tão próximo do disco quanto o da base. Qual seria a melhor localização dos dados? Próximo da aplicação, que é quem vai processar e gerar informação ou próximo da base que é quem vai guardar os dados? Pois para mim não adianta ficar lá na base tão bem guardados que nunca chegam ao cliente, se é que me entendem. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Two Phase Commit
Pessoal, Gostaria de saber se existe a possibilidade de fazer two phase commit em agrupamentos distintos no PostgreSQL 9 ou superior. Pode ser inclusive com auxilio de algum pacote contrib ou projeto externo. Grato, Rogério Bassete ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Qual o problema? Concordo, não vejo problema a não ser quando o mesmo usuário é usado em vários logins ao mesmo tempo e em diferentes lugares, fora isso acho que é bem fácil de resolver. Nesse caso, a gente volta à solução ideal — o cliente tem de informar à aplicação onde está — e ao contorno — o usuário terá de informar toda vez que abrir uma sessão. Concordo e esta função deve ficar a cargo da aplicação, já que ela é quem acompanha o usuário. Na prática a teoria é outra coisa. Nada a ver. Teoria é explicação da realidade, só isso. Desculpe-me, mas teoria é um ponto de vista de um mundo ideal e que sabemos fica bem longe do mundo real. Cada ponto de vista representa uma teoria. Quando não corresponder à realidade, busca‐se outra teoria que corresponda melhor. Ainda não arranjaram teoria melhor que o modelo relacional. É como Unix: quem não conhece, está sujeito a cometer os mesmo erros vez após vez. E hoje temos a lei de Moore para camuflar os problemas até que seja tarde demais para consertá‐los. As vezes é bom não ter regras e as vezes é bom ter regras, às vezes é bom ter relacionamentos e às vezes não. Concordo que o modelo relacional esta bem consolidado, mas realmente precisamos relacionar todos os nossos dados? Em transações bancárias por exemplo sim, mas e nas outras aplicações? Creio que um modelo hibrido seria bom onde objetos complexos vivem em harmonia com o modelo relacional. Claro cada situação é uma situação. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Em 13/10/2011 15:59, Shander Lyrio escreveu: Em 13-10-2011 15:39, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/13 Shander Lyrioshan...@nucleo45.com.br: O problema ocorre quando vários clientes de fusos horários diferentes tem seu sistema hospedado em um mesmo servidor, o que não é incomum em SaaS. Se o sistema roda no servidor, isso é bom — mas, se isso significa que ele não se comunica com o cliente, isso é ruim. Nesse caso, a informação teria de ser prestada pelo usuário. O Sistema roda na Web, um browser não passa automaticamente o fuso horário numa requisição http, também não tem como você pedir para o browser te passar esta informação do sistema operacional do usuário por questões de segurança. Todo sistema cliente/servidor tem que se comunicar obviamente com o servidor, senão não seria necessário o segundo, o que é comunicado é a questão. Pela sua colocação então, todos os sistemas web que rodam em algum browser são ruins. Creio que seja mais fácil do que você colocou em sua argumentação e que pelo contrário seja uma questão de segurança saber a que real horário o cliente acessou a sua máquina, se não seria a segurança do *indows você não tem acesso ao código fonte logo você esta seguro, é só uma analogia. Bom ou Ruim depende de contexto e a afirmação categórica de algum deles sem contexto é irrelevante. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Pessoal, então se em uma aplicação WEB não tem como solicitar do browser a localização do usuário, então nos resta pré-cadastrar se um estado está ou não utilizando o horário de verão e setar o timezone da sessão de acordo com esta informação. Correto? Abraços Em 13 de outubro de 2011 16:12, Flávio Alves Granato flavio.gran...@gmail.com escreveu: Qual o problema? Concordo, não vejo problema a não ser quando o mesmo usuário é usado em vários logins ao mesmo tempo e em diferentes lugares, fora isso acho que é bem fácil de resolver. Nesse caso, a gente volta à solução ideal — o cliente tem de informar à aplicação onde está — e ao contorno — o usuário terá de informar toda vez que abrir uma sessão. Concordo e esta função deve ficar a cargo da aplicação, já que ela é quem acompanha o usuário. Na prática a teoria é outra coisa. Nada a ver. Teoria é explicação da realidade, só isso. Desculpe-me, mas teoria é um ponto de vista de um mundo ideal e que sabemos fica bem longe do mundo real. Cada ponto de vista representa uma teoria. Quando não corresponder à realidade, busca‐se outra teoria que corresponda melhor. Ainda não arranjaram teoria melhor que o modelo relacional. É como Unix: quem não conhece, está sujeito a cometer os mesmo erros vez após vez. E hoje temos a lei de Moore para camuflar os problemas até que seja tarde demais para consertá‐los. As vezes é bom não ter regras e as vezes é bom ter regras, às vezes é bom ter relacionamentos e às vezes não. Concordo que o modelo relacional esta bem consolidado, mas realmente precisamos relacionar todos os nossos dados? Em transações bancárias por exemplo sim, mas e nas outras aplicações? Creio que um modelo hibrido seria bom onde objetos complexos vivem em harmonia com o modelo relacional. Claro cada situação é uma situação. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Pedro Ivo Bispo de França X-Brain - Desenvolvimento de Sistemas Ltda Contato: +55 43 3304-2204 | +55 43 9608-3678 Avenida Tiradentes, 501 Sala 702 Torre 1 - Jd. Shangrilá Londrina - Paraná - 86070-545 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 13 de outubro de 2011 15:44, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2011/10/13 Shander Lyrio shan...@nucleo45.com.br: O que seria chave natural para um cadastro de clientes?? cpf se for física ou cnpj se for jurídica? existe alguma melhor? e quando a esposa e o marido usam o mesmo cpf ou cara é de fora do Brasil e seu documento chama-se passaporte? e quando várias empresas usarem o mesmo cnpj como é o caso de um colega do sul que presta serviço à escolas que se não me engano tem o mesmo cnpj? Isso já foi discutido aqui na lista diversas vezes. Sim, e a conclusão sempre foi a mesma: em última instância, a chave natural pode vir a ser a tabela toda, excluídos atributos artificiais. Se nem isso identificar, então a base de dados será inconsistente. Discordo do uso indiscriminado de chaves artificiais, isso traz mais malefícios do que benefícios. No entanto, na minha opinião o código do cliente não é uma chave artificial, pois ele aparece fora da aplicação. Nas nossas contas de luz, telefone, etc está impresso nosso número de cliente, por exemplo. Da mesma forma, o número do pedido também é relevante fora da aplicação, vem do tempo em que os comerciantes preenchiam à mão talões numerados mecanicamente (na gráfica). Essa é uma realidade que existe desde o início do século passado, temos que levar isto em consideração. -- Atenciosamente, Alexsander da Rosa http://rednaxel.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] Configurando Timezones por databases
Em 13/10/2011 16:16, Pedro Ivo Bispo França escreveu: Pessoal, então se em uma aplicação WEB não tem como solicitar do browser a localização do usuário, então nos resta pré-cadastrar se um estado está ou não utilizando o horário de verão e setar o timezone da sessão de acordo com esta informação. Correto? Não há necessidade, o google já faz essa localização bem precisa em suas aplicações, claro utilizando de outros meios para pegar esta localização mais precisa, mas me pergunto se já pego qual a língua do browser para eu mostrar a linguagem nativa do usuário na aplicação, então o que me impediria de pegar também o fuso horário dele? Nada. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Pelo Google achei comentários como o [1] que menciona a respeito de pegar a hora do cliente e não do servidor através de linguagem. Seria a isso que que se refere? [1] http://www.hardware.com.br/comunidade/hora-php/966338/ Abraços, Eduardo Alexandre Em 13 de outubro de 2011 16:25, Flávio Alves Granato flavio.gran...@gmail.com escreveu: Não há necessidade, o google já faz essa localização bem precisa em suas aplicações, claro utilizando de outros meios para pegar esta localização mais precisa, mas me pergunto se já pego qual a língua do browser para eu mostrar a linguagem nativa do usuário na aplicação, então o que me impediria de pegar também o fuso horário dele? Nada. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 13-10-2011 15:44, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/13 Shander Lyrioshan...@nucleo45.com.br: O que seria chave natural para um cadastro de clientes?? cpf se for física ou cnpj se for jurídica? existe alguma melhor? e quando a esposa e o marido usam o mesmo cpf ou cara é de fora do Brasil e seu documento chama-se passaporte? e quando várias empresas usarem o mesmo cnpj como é o caso de um colega do sul que presta serviço à escolas que se não me engano tem o mesmo cnpj? Isso já foi discutido aqui na lista diversas vezes. Sim, e a conclusão sempre foi a mesma: em última instância, a chave natural pode vir a ser a tabela toda, excluídos atributos artificiais. Se nem isso identificar, então a base de dados será inconsistente. Certo, num cadastro de clientes deveríamos colocar todos os campos como chave primária. É esta sua opinião? Porque se for, ela contraria as suas colocações anteriores de que se a chave fosse natural estaria em memória, seria mais rápido fazer consultas, etc, etc, etc.. Estou quase convencido que não existe uma chave natural perfeita para este simples cadastro de clientes, que tal um sequenciamento genético? Hum não funcionaria em empresas!!! Sequenciamento genético com os donos?? A!!! E quando a empresa fosse S/A?? Poxa!!! Quem perde a calma perde a razão. Não perdi a calma não, eu estou escrevendo este e-mail até rindo. Acho engraçado você defender tanto a teoria quando não consegue pela teoria se justificar com um fato real simples como esse. Você já parou para pensar que quando algo vai para o cache do PostGreSql, a página de dados toda vai para o cache?? Por favor, o nome do sistema é PostgreSQL ou Postgres. Você vive de teoria de banco de dados, um monte de falácia que quando confrontada com a realidade, não consegue se sustentar. Você sequer conseguiu explicar como ter uma chave natural fiável num simples cadastro de clientes, e tenta mudar o assunto chamando atenção para a forma que eu coloco a caixa alta ou baixa no meu texto? não são simplesmente os dados, mas toda a página, com todos os campos. Ela pode inclusive estar cheia de buracos de registros já apagados e atualizados que ainda não foram recuperados com um vacuum, um campo a mais indo para o cache vai impactar um pentelhésimo de segundo ou nada. Se estivermos falando do que está definido no effective_cache_size, o assunto é ainda mais complexo, porque apenas os campos selecionados vão para esta área da memória para as agregação, join, e etc. E daí? E daí que seu argumento de cache sujo por causa de uma chave artificial cai por terra, porque ele é muito mais do que sujo, antes mesmo de a chave artificial existir. Ou seja, o fato de a chave artificial sujar o cache é absolutamente irrelevante. Pessoalmente acho que o melhor custo/benefício é trabalhar com o cache da aplicação, ele bem administrado vai reduzir drasticamente a quantidade de consultas enviadas para o banco de dados. O seu achômetro pessoal vai contra a experiência geral da humanidade. O cache da aplicação tem seu lugar, mas ele não está tão próximo do disco quanto o da base. Você *acha* que a experiência geral da humanidade é esta. Eu estou falando de custo/benefício e não qual cache é melhor. O que você pode fazer de efetivo para melhorar o desempenho da aplicação com relação ao cache do banco de dados?? Nada ou bem próximo disso!! Aumentar o cache pode ser feito com ou sem ORM, então nem conta. Trabalhando em um cache de aplicação eu posso ser muito mais efetivo porque vou criar um ganho real para a aplicação e alivar a quantidade de consultas ao banco de dados, independente do ganho que o cache de banco de dados já me proporciona. Entendeu agora?? custo/benefício. Com relação ao cache de banco nada pode ser feito senão aumentar ou diminuir ele, na aplicação muito pode ser feito, por isso insisto no tema. Trabalhar junto! Desenvolvimento + Banco de dados para o sucesso do conjunto!! E, para isso, quem tem a visão geral dos dados é o AD, que pode ou não ser o DBA. Suas respostas estão sendo dadas como DBA ou como AD? De qualquer forma acredito que você esteja vendo a situação apenas de um ângulo. Se eu economizo várias horas de programação da equipe eu tenho mais condições de barganhar um sistema de discos melhor, mais memória, mais processador. O que não adianta nada quando a aplicação não escala e a base é inconsistente. Na prática a teoria é outra. Os bancos de dados mais escaláveis não tem nada de consistentes, nada de primary keys ou foreign keys, restrição de campos, unique, rigidez de estrutura das tabelas, etc. Vide vários noSql que estão por aí ganhando terreno onde escalabilidade é o fator importante. Na prática, um certo nível de inconsistência desde que controlado é facilmente absorvido. Sei que alguns colegas respondem como se
Re: [pgbr-geral] Two Phase Commit
Gostaria de saber se existe a possibilidade de fazer two phase commit em agrupamentos distintos no PostgreSQL 9 ou superior. Pode ser inclusive com auxilio de algum pacote contrib ou projeto externo. O PostgreSQL tem total suporte a 2PC. Só cuidado pra não cair no dilema quero x peço y que citaram outro dia desses aqui na lista. 2PC é a saída pra você mesmo? O que *exatamente* você quer fazer? []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] Configurando Timezones por databases
Em 13/10/2011 16:27, Eduardo Alexandre escreveu: Pelo Google achei comentários como o [1] que menciona a respeito de pegar a hora do cliente e não do servidor através de linguagem. Seria a isso que que se refere? [1] http://www.hardware.com.br/comunidade/hora-php/966338/ Sim, é disso mesmo que falo. Saber qual o momento certo seu usuário logou na aplicação é importante e crítico. Pois ajuda resolver casos de acesso indevido, ataque e até mesmo melhorar seu relacionamento com ele, vide aqueles serviços onde seu suporte esta onde a luz do sol esta iluminando o mundo. Logo, você não precisa pagar adicional noturno e nem perder o suporte a seu cliente. Bem é para empresas globais. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
E analisando aqui, o pior não é nem descobrir a timezone do cliente. É descobrir se ele está adotando ou não o bendito horário de verão. Isso é uma questão política e não só geográfica. (A bahia está entrando recentemente no horário de verão se não me engano) Tem como saber se o usuário está ou não sob efeito do horário de verão somente vendo a timezone em que ele se encontra? Em 13 de outubro de 2011 16:27, Eduardo Alexandre eduardog...@gmail.comescreveu: Pelo Google achei comentários como o [1] que menciona a respeito de pegar a hora do cliente e não do servidor através de linguagem. Seria a isso que que se refere? [1] http://www.hardware.com.br/comunidade/hora-php/966338/ Abraços, Eduardo Alexandre Em 13 de outubro de 2011 16:25, Flávio Alves Granato flavio.gran...@gmail.com escreveu: Não há necessidade, o google já faz essa localização bem precisa em suas aplicações, claro utilizando de outros meios para pegar esta localização mais precisa, mas me pergunto se já pego qual a língua do browser para eu mostrar a linguagem nativa do usuário na aplicação, então o que me impediria de pegar também o fuso horário dele? Nada. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Pedro Ivo Bispo de França X-Brain - Desenvolvimento de Sistemas Ltda Contato: +55 43 3304-2204 | +55 43 9608-3678 Avenida Tiradentes, 501 Sala 702 Torre 1 - Jd. Shangrilá Londrina - Paraná - 86070-545 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Em 13/10/2011 16:53, Pedro Ivo Bispo França escreveu: E analisando aqui, o pior não é nem descobrir a timezone do cliente. É descobrir se ele está adotando ou não o bendito horário de verão. Isso é uma questão política e não só geográfica. (A bahia está entrando recentemente no horário de verão se não me engano) Tem como saber se o usuário está ou não sob efeito do horário de verão somente vendo a timezone em que ele se encontra? Agora tem, já que o Lula sancionou a lei que fixa os dias de início e fim do horário de verão. Agora quais dias, já são outra história e não é um dia fixo do mês, se não me engano é tipo segundo sábado de outubro e segundo sábado de fevereiro... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Two Phase Commit
2PC é a saída pra você mesmo? O que *exatamente* você quer fazer? Tenho clientes no seguinte cenário: Server01 - IP 200.x.x.x:5432 (Matriz) Server02 - IP 201.x.x.x:5432 (Filial 01) Server03 - IP 202.x.x.x:5432 (Filial 02) Quero abrir uma transação entre os 3 servidores distintos, inserir um registro e commitar tudo. Grato, Rogério A Bassete ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Two Phase Commit
2011/10/13 Rogerio Bassete roge...@microwork.inf.br: 2PC é a saída pra você mesmo? O que *exatamente* você quer fazer? Quero abrir uma transação entre os 3 servidores distintos, inserir um registro e commitar tudo. Lembra que, com replicação, a dependência da disponibilidade dos três, e da comunicação entre eles, é menor. Essencialmente, consideras que cada informação mora num servidor e é replicada para os outros sempre que possível. Pode não ser adequado, porque ainda não sabemos porque queres fazer o que queres fazer, mas é uma idéia 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] Configurando Timezones por databases
2011/10/13 Shander Lyrio shan...@nucleo45.com.br: O Sistema roda na Web, um browser não passa automaticamente o fuso horário numa requisição http, também não tem como você pedir para o browser te passar esta informação do sistema operacional do usuário por questões de segurança. Que questões? Pergunta de leigo… Me corrija se estiver errado, mas hoje pode‐se determinar com precisão razoável onde está o usuário, no limite pede‐se que ele confirme a informação ao abrir ou a sessão, ou a transação. …o que é comunicado é a questão. Pela sua colocação então, todos os sistemas web que rodam em algum browser são ruins. E isso seria absurdo, se for verdade? Em última instância, pergunta‐se ao usuário. O que é ruim, mas pode resolver. Seu CPD pode estar em São Paulo, importar os arquivos de carga do cliente, a coleta destes documentos serem descentralizadas e alguém em Pernambuco lançar a coleta deste documento uns minutos depois. No tracking você vai ver algo bizarro como a coleta ser realizada antes do arquivo ter sido processado pelo cliente. Ou seja, um problema de procedimento… Nada a ver. Teoria é explicação da realidade, só isso. Teoria é a tentativa de explicação da realidade pelos olhos de quem tentou dar esta explicação. Vista de apenas um ângulo é no mínimo limitada. Por isso é debatida publicamente. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Two Phase Commit
Em 13 de outubro de 2011 17:21, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2011/10/13 Rogerio Bassete roge...@microwork.inf.br: 2PC é a saída pra você mesmo? O que *exatamente* você quer fazer? Quero abrir uma transação entre os 3 servidores distintos, inserir um registro e commitar tudo. Você pode utilizar então 2PC: http://www.postgresql.org/docs/9.1/static/sql-prepare-transaction.html Está disponível pelo menos desde o PostgreSQL 8.2 (talvez antes, não tenho certeza nem documentação disponível). Lembra que, com replicação, a dependência da disponibilidade dos três, e da comunicação entre eles, é menor. Essencialmente, consideras que cada informação mora num servidor e é replicada para os outros sempre que possível. Pode não ser adequado, porque ainda não sabemos porque queres fazer o que queres fazer, mas é uma idéia geral. Traduzindo o que o Dutra falou: Se um dos três nós morrer ou ficar sem comunicação, você não vai conseguir comitar nenhum. Talvez alguma técnica de replicação assíncrona (ex.: Bucardo) possa fazer o que você quer sem indisponibilidade. []s Flavio ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
2011/10/13 Flávio Alves Granato flavio.gran...@gmail.com: As vezes é bom não ter regras e as vezes é bom ter regras Se não há regras, não há como criar um sistema… um sistema sem regras é um sistema inconsistente. às vezes é bom ter relacionamentos e às vezes não. Concordo que o modelo relacional esta bem consolidado, mas realmente precisamos relacionar todos os nossos dados? Mas o modelo relacional não tem nada a ver com relacionamentos! Ele é sobre relações (tabelas com chave(s) natural(is) declarada(s)), não sobre relacionamentos entre relações. Em transações bancárias por exemplo sim, mas e nas outras aplicações? Creio que um modelo hibrido seria bom onde objetos complexos vivem em harmonia com o modelo relacional. Claro cada situação é uma situação. Esse modelo é o relacional, vide _The Third Manifest_… o modelo relacional não está bem implementado nem na linguagem SQL em si, nem nas implementações SQL (SGBDs), mas isso são restrições tecnológicas arbitrárias, não problemas do modelo. Sabendo dessas limitações, pode‐se decidir por violar o modelo em alguns casos, como por exemplo criar chaves artificiais onde absolutamente necessário; violá‐lo sistematicamente é pedir para apanhar da vida. Para resumir, classes de OO equivalem a tipos de dados no modelo relacional. E, portanto, OO e o modelo relacional são ortogonais. Só entram em conflito quando quem não conhece o modelo relacional tenta reinventar a roda aplicando uma técnica de programação, que é a OO, na gestão de dados. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
2011/10/13 Eduardo Alexandre eduardog...@gmail.com: Pelo Google achei comentários como o [1] que menciona a respeito de pegar a hora do cliente e não do servidor através de linguagem. Seria a isso que que se refere? [1] http://www.hardware.com.br/comunidade/hora-php/966338/ Basicamente sim, mas não basta a hora: tem de saber a diferença para UTC, e isso se sabe pela cidade de referência do fuso. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
2011/10/13 Pedro Ivo Bispo França pe...@xbrain.com.br: E analisando aqui, o pior não é nem descobrir a timezone do cliente. É descobrir se ele está adotando ou não o bendito horário de verão. Por isso que se deve usar não a diferença de fuso (+2 ou -3, por exemplo), mas o nome do fuso ou, mais claramente, a cidade de referência. Isso é uma questão política e não só geográfica. (A bahia está entrando recentemente no horário de verão se não me engano) Todas essas informações políticas estão disponíveis na última base de dados de fusos horários, que foi recentemente tirada do ar; atualizações desde então, até que o litígio que a tirou do ar acabe, ficam a cargo do freguês. Para o Brasil, o Observatório Nacional publica todas as alterações com antecedência. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
2011/10/13 Flávio Alves Granato flavio.gran...@gmail.com: Agora tem, já que o Lula sancionou a lei que fixa os dias de início e fim do horário de verão. O problema não é haver lei, que sempre houve, mas o governo resistir a emitir medidas provisórias acochambrando para a Globo transmitir a visita do Papa, a Copa do mundo e coisas assim. Agora quais dias, já são outra história e não é um dia fixo do mês, se não me engano é tipo segundo sábado de outubro e segundo sábado de fevereiro... Procure por ‘TZ database’. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
2011/10/13 Shander Lyrio shan...@nucleo45.com.br: Responder perguntas sempre dizendo, que se deveria procurar uma chave natural, ou que se estivesse usando chave natural isso ou aquilo não aconteceria, ou ainda que sugiro que procure chave natural não resolve o problema de ninguém, principalmente quando não se consegue achar uma única chave natural viável nem num simples cadastro de clientes. Sempre há uma chave natural. Pode ser que, por limitações tecnológicas, seja necessário acrescentar uma artificial, mas nunca à exclusão de ao menos uma natural. A pena é inconsistência da base. Apenas põe mais dúvida na cabeça do povo, que vai consultar a teoria no livro do Date e sabe o que o cara vai encontrar lá?? id_customer, id_dept, id_employer, id_state ... e não adianta dizer para procurar em outros livros, eu já li vários e é sempre a mesma coisa. O livro do Date é para ser usado, não adorado. Sim, ele coloca ids; não, não quer dizer que ele advogue chaves artificiais. Nem todo id é artificial, e muitas vezes se simplifica um exemplo porque o assunto não é chave. Vou tentar escrever para ele sugerindo esclarece isso na próxima edição, mas o problema é do leitor: perceber que os exemplos não são explanação de princípios. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
2011/10/13 Flavio Henrique Araque Gurgel fha...@gmail.com: Basicamente sim, mas não basta a hora: tem de saber a diferença para UTC, e isso se sabe pela cidade de referência do fuso. A hora GMT é a hora zero de onde os fusos horários são calculados. Em Informática, GMT foi substituída pela UTC. Tratar a hora no SGBD como GMT é uma boa. Por isso o WITH TIME ZONE. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Em 13-10-2011 16:16, Pedro Ivo Bispo França escreveu: Pessoal, então se em uma aplicação WEB não tem como solicitar do browser a localização do usuário, então nos resta pré-cadastrar se um estado está ou não utilizando o horário de verão e setar o timezone da sessão de acordo com esta informação. Correto? Acredito que sim, infelizmente, nem pelo ip você consegue uma informação fiável do estado em que o usuário está se conectando. Aqui temos trabalhado desta forma há 4 anos sem problemas. Também é a forma utilizada pela maioria, senão todos os sites de CMS ou foruns internacionais, no momento do cadastro do usuário é você informa sua timezone. Uma outra forma seria você pegar via JavaScript a hora da máquina do usuário mas eu não gosto muito desta opção já que a alteração no sistema seria muito maior para popular todas as requisições feitas ao servidor de aplicação. Abraço, -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/13 Alexsander Rosa alexsander.r...@gmail.com: Discordo do uso indiscriminado de chaves artificiais, isso traz mais malefícios do que benefícios. No entanto, na minha opinião o código do cliente não é uma chave artificial, pois ele aparece fora da aplicação. Perfeitamente! E por isso mesmo pode‐se, e deve‐se sempre que possível, declarar mais de uma chave natural — não confundir com chave simples versus composta. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Two Phase Commit
Você pode utilizar então 2PC: http://www.postgresql.org/docs/9.1/static/sql-prepare-transaction.html Está disponível pelo menos desde o PostgreSQL 8.2 (talvez antes, não tenho certeza nem documentação disponível). Como nunca usei 2PC, já li essa página do manual e não consegui simular. Na internet encontrei um exemplo de 2PC via psql, porém, no mesmo cluster, usando \connect. Não sei se vocês notaram, mas os servidores PostgreSQL ficam em hosts diferentes. Alguém poderia me fornecer um exemplo em psql ou link de uso de 2PC em clusters distintos. Traduzindo o que o Dutra falou: Se um dos três nós morrer ou ficar sem comunicação, você não vai conseguir comitar nenhum. É exatamente isso que preciso, ou grava nos 3 ou em nenhum. Replicação nenhuma me atende no momento. Grato, Rogério A. Bassete ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Two Phase Commit
2011/10/13 Rogerio Bassete roge...@microwork.inf.br: Alguém poderia me fornecer um exemplo em psql ou link de uso de 2PC em clusters distintos. Não muda nada, porque cada cluster escuta numa porta diferente… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Em 13-10-2011 16:25, Flávio Alves Granato escreveu: Em 13/10/2011 16:16, Pedro Ivo Bispo França escreveu: Pessoal, então se em uma aplicação WEB não tem como solicitar do browser a localização do usuário, então nos resta pré-cadastrar se um estado está ou não utilizando o horário de verão e setar o timezone da sessão de acordo com esta informação. Correto? Não há necessidade, o google já faz essa localização bem precisa em suas aplicações, claro utilizando de outros meios para pegar esta localização mais precisa, mas me pergunto se já pego qual a língua do browser para eu mostrar a linguagem nativa do usuário na aplicação, então o que me impediria de pegar também o fuso horário dele? Nada. O que impediria o fato de que a língua pode ser configurada no browser, se você configura errado vem informação errada, mas seu timezone não pode ser configurado no browser, até porque, voce com seu notebook no Recife ou no Acre, seu idioma não muda, mas seu timezone com certeza sim. Abraço, -- Shander Lyrio http://about.com/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Two Phase Commit
Não muda nada, porque cada cluster escuta numa porta diferente… Leandro, sem querer abusar, pode me fornecer um LOG do psql que simula isso de exemplo? Grato, Rogério A Bassete ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Em transações bancárias por exemplo sim, mas e nas outras aplicações? Creio que um modelo hibrido seria bom onde objetos complexos vivem em harmonia com o modelo relacional. Claro cada situação é uma situação. Esse modelo é o relacional, vide _The Third Manifest_… o modelo relacional não está bem implementado nem na linguagem SQL em si, nem nas implementações SQL (SGBDs), mas isso são restrições tecnológicas arbitrárias, não problemas do modelo. Sabendo dessas limitações, pode‐se decidir por violar o modelo em alguns casos, como por exemplo criar chaves artificiais onde absolutamente necessário; violá‐lo sistematicamente é pedir para apanhar da vida. Para resumir, classes de OO equivalem a tipos de dados no modelo relacional. E, portanto, OO e o modelo relacional são ortogonais. Só entram em conflito quando quem não conhece o modelo relacional tenta reinventar a roda aplicando uma técnica de programação, que é a OO, na gestão de dados. Onde se encaixa o modelo não relacional nesta teoria? O famoso NoSQL, agora viu que não disse programação OO. Sim, acho que não é necessário implementar a complexidade de um modelo relacional em todas as situaçãos, apesar de ele poder ser usado. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Em 13/10/2011 17:54, Shander Lyrio escreveu: Em 13-10-2011 16:25, Flávio Alves Granato escreveu: Em 13/10/2011 16:16, Pedro Ivo Bispo França escreveu: Pessoal, então se em uma aplicação WEB não tem como solicitar do browser a localização do usuário, então nos resta pré-cadastrar se um estado está ou não utilizando o horário de verão e setar o timezone da sessão de acordo com esta informação. Correto? Não há necessidade, o google já faz essa localização bem precisa em suas aplicações, claro utilizando de outros meios para pegar esta localização mais precisa, mas me pergunto se já pego qual a língua do browser para eu mostrar a linguagem nativa do usuário na aplicação, então o que me impediria de pegar também o fuso horário dele? Nada. O que impediria o fato de que a língua pode ser configurada no browser, se você configura errado vem informação errada, mas seu timezone não pode ser configurado no browser, até porque, voce com seu notebook no Recife ou no Acre, seu idioma não muda, mas seu timezone com certeza sim. Concordo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Em 13-10-2011 16:17, Flávio Alves Granato escreveu: Creio que seja mais fácil do que você colocou em sua argumentação e que pelo contrário seja uma questão de segurança saber a que real horário o cliente acessou a sua máquina, se não seria a segurança do *indows Você não tem como garantir que o horário da máquina do usuário esteja correto a não ser que seja um ambiente controlado. Com JavaScript você consegue o horário, mas este horário está atualizado com o horário de verão ou não? está correto? Todos os browsers respondem da mesma forma? Além disso, você precisaria mudar toda a aplicação para em cada requisição ao servidor de aplicações começar a enviar este horário também como parâmetro o que raramente é uma opção. Abraço, -- Shander Lyrio http://about.com/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
O mais simples é isso mesmo, o usuário informa sua timezone. Num ERP isto pode ser implícito, o usuário pode ser cadastrado com uma TZ fixa ou a TZ pode ser associada ao servidor onde ele está se logando. Um funcionário do operacional pode nem saber que existe TZ e esta ser fixa no seu cadastro; um usuário gerencial pode informar em que filial ele quer se logar e o sistema pegar a TZ dela. Em 13 de outubro de 2011 17:50, Shander Lyrio shan...@nucleo45.com.br escreveu: Em 13-10-2011 16:16, Pedro Ivo Bispo França escreveu: Pessoal, então se em uma aplicação WEB não tem como solicitar do browser a localização do usuário, então nos resta pré-cadastrar se um estado está ou não utilizando o horário de verão e setar o timezone da sessão de acordo com esta informação. Correto? Acredito que sim, infelizmente, nem pelo ip você consegue uma informação fiável do estado em que o usuário está se conectando. Aqui temos trabalhado desta forma há 4 anos sem problemas. Também é a forma utilizada pela maioria, senão todos os sites de CMS ou foruns internacionais, no momento do cadastro do usuário é você informa sua timezone. -- Atenciosamente, Alexsander da Rosa http://rednaxel.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] Configurando Timezones por databases
Em 13-10-2011 17:26, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/13 Shander Lyrioshan...@nucleo45.com.br: O Sistema roda na Web, um browser não passa automaticamente o fuso horário numa requisição http, também não tem como você pedir para o browser te passar esta informação do sistema operacional do usuário por questões de segurança. Que questões? Pergunta de leigo… Alguém(s) resolveu restrigir as coisas que um browser pode ou não fazer para evitar a propagação de vírus, imagina entrar em um site sem querer e automaticamente estar contaminado. Por isso qualquer acesso direto ao SO é barrada. Me corrija se estiver errado, mas hoje pode‐se determinar com precisão razoável onde está o usuário, no limite pede‐se que ele confirme a informação ao abrir ou a sessão, ou a transação. Exato, em um ambiente como o google com milhões de usuários, possivelmente milhares da sua localidade ou com número de ip parecido já cadastraram anteriormente suas localizações. A estatística te dá uma precisão razoável. Se alguém conseguir estas informações do google será um afortunado. …o que é comunicado é a questão. Pela sua colocação então, todos os sistemas web que rodam em algum browser são ruins. E isso seria absurdo, se for verdade? Se você não tem uma opção melhor para resolver o problema, remar contra a solução te faz parte do problema. Ela não precisa ser uma boa solução no amplo sentido da palavra, basta ser melhor que a que já exite e já vai ter o seu devido mérito. Em última instância, pergunta‐se ao usuário. O que é ruim, mas pode resolver. Isto acontece inúmeras vezes, e se a opção ruim que você der for melhor do que a que ele tem atualmente, você já avançou muito. Seu CPD pode estar em São Paulo, importar os arquivos de carga do cliente, a coleta destes documentos serem descentralizadas e alguém em Pernambuco lançar a coleta deste documento uns minutos depois. No tracking você vai ver algo bizarro como a coleta ser realizada antes do arquivo ter sido processado pelo cliente. Ou seja, um problema de procedimento… A informática existe para resolver estes problemas. Cadastrar o timezone de cada um uma única vez no sistema resolve este problema de procedimento. É mais fácil ter um campo de timezone do que impedir a coleta descentralizada de documentos. Esta coleta descentralizada reduz o custo de movimentação de cargas de forma gigantesca. Por isso é debatida publicamente. E nunca se chega a um consenso que abranja todos os problemas. Abraço, -- Shander Lyrio http://about.com/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Configurando Timezones por databases
Em 13/10/2011 18:18, Shander Lyrio escreveu: Em 13-10-2011 16:17, Flávio Alves Granato escreveu: Creio que seja mais fácil do que você colocou em sua argumentação e que pelo contrário seja uma questão de segurança saber a que real horário o cliente acessou a sua máquina, se não seria a segurança do *indows Você não tem como garantir que o horário da máquina do usuário esteja correto a não ser que seja um ambiente controlado. Com JavaScript você consegue o horário, mas este horário está atualizado com o horário de verão ou não? está correto? Todos os browsers respondem da mesma forma? Além disso, você precisaria mudar toda a aplicação para em cada requisição ao servidor de aplicações começar a enviar este horário também como parâmetro o que raramente é uma opção. Abraço, Sim e raramente é um requisito funcional. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Alexandre, poderia citar os malefícios das chaves artificiais? Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2011/10/13 Alexsander Rosa alexsander.r...@gmail.com: Discordo do uso indiscriminado de chaves artificiais, isso traz mais malefícios do que benefícios. No entanto, na minha opinião o código do cliente não é uma chave artificial, pois ele aparece fora da aplicação. Perfeitamente! E por isso mesmo pode‐se, e deve‐se sempre que possível, declarar mais de uma chave natural — não confundir com chave simples versus composta. ___ 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] Mes anterior de uma data
pessoal, como eu faço para pegar o mês anterior de uma data via SQL? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Mes anterior de uma data
On Thu, Oct 13, 2011 at 8:04 PM, Pedro B. Alves pedroalve...@gmail.com wrote: pessoal, como eu faço para pegar o mês anterior de uma data via SQL? SELECT CURRENT_DATE - interval '1 month'; -Leo -- Leonardo Cezar http://postgreslogia.wordpress.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] Two Phase Commit
Leandro, sem querer abusar, pode me fornecer um LOG do psql que simula isso de exemplo? Imagine assim: Servidores A, B e C Comece a transação em cada um: A BEGIN; B BEGIN; C BEGIN; Faça alguma coisa em cada servidor: A INSERT INTO foo VALUES (1,2,3,4); B INSERT INTO foo VALUES (1,2,3,4); C INSERT INTO foo VALUES (1,2,3,4); Agora tente preparar as transações: A PREPARE TRANSACTION 'xpto'; B PREPARE TRANSACTION 'xpto'; C PREPARE TRANSACTION 'xpto'; A sua aplicação deve ter ciência que os três PREPARE acima deram certo. Se *todos* derem certo: A COMMIT PREPARED 'xpto'; B COMMIT PREPARED 'xpto'; C COMMIT PREPARED 'xpto'; Terminou. Agora vamos simular um erro no servidor B, se o PREPARE TRANSACTION falhar no B, você deverá fazer: A ROLLBACK PREPARED 'xpto'; C ROLLBACK PREPARED 'xpto'; E emitir um erro para seu usuário. Feito. PREPARE TRANSACTION é totalmente ACID, ou seja, atômico, garantido e persistente. Imagine que na hora do COMMIT, um dos servidores falhe! você pode fazer o COMMIT depois que esse servidor voltar, pois o PREPARE TRANSACTION já garantiu isso de forma persistente, em disco. Cuide apenas para que nenhum dos PREPARE TRANSACTION fique sem seu respectivo COMMIT ou ROLLBACK. []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] Two Phase Commit
Le 2011-O-13 17h56, Rogerio Bassete a écrit : Não muda nada, porque cada cluster escuta numa porta diferente… Leandro, sem querer abusar, pode me fornecer um LOG do psql que simula isso de exemplo? Desculpa, não estou em condições de montar um testes agora… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/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] Configurando Timezones por databases
Le 2011-O-13 18h5, Flávio Alves Granato a écrit : Onde se encaixa o modelo não relacional nesta teoria? O famoso NoSQL, agora viu que não disse programação OO. Sim, acho que não é necessário implementar a complexidade de um modelo relacional em todas as situaçãos, apesar de ele poder ser usado. Acho que estou lesado, não entendi… o modelo relacional é mais simples, a complexidade fica toda dentro dos tipos… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/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] Configurando Timezones por databases
Le 2011-O-13 18h12, Shander Lyrio a écrit : Sempre há uma chave natural, quase nunca faz sentido usá-la. Absurdo. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/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] Two Phase Commit
2011/10/13 Flavio Henrique Araque Gurgel fha...@gmail.com: [corte] A sua aplicação deve ter ciência que os três PREPARE acima deram certo. Se *todos* derem certo: A COMMIT PREPARED 'xpto'; B COMMIT PREPARED 'xpto'; C COMMIT PREPARED 'xpto'; Terminou. Utilize a função pg_prepared_xact() em seus servidores para verificar quais possuem transações pendentes. momento-propaganda Assista minha palestra no PGBR2011 para mais informações sobre funções úteis do servidor. /momento-propaganda -Leo -- Leonardo Cezar http://postgreslogia.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
