Re: [pgbr-geral] formatação_Moeda.
REPLACE(TRIM(TO_CHAR(CAMPO, REPLACE('99G999D99' ,'G', ' '))), ' ', '.');
- ASSIM ESTÁ CORRETO.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Alteração do postgresql.conf
Não estou conseguindo alterar os parâmetros no postgresql.conf : #datestyle = 'ISO, MDY' datestyle = 'SQL, EUROPEAN' #LC_MONERATY = 'C' #LC_NUMERIC= 'C' LC_MONERATY = 'pt_BR' LC_NUMERIC= 'pt_BR' Se alterar estes parâmetros não consegui startar o banco. OBS - PostgresSQL 8.2.4 Win32 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Na verdade eu fao o backup e o restore com os comandos citados, consequentemente (e segundo a verbose do restore e o log do banco) simplificadamente primeiro criada a estrutura do banco, depois so carregados os dados e finalmente aplicadas as restries. O intrigante que apenas a restrio citada que consome tanto tempo (12 horas). Todo o mais consome 2 horas. Ontem a noite eliminei manualmente a constraint e reapliquei-a. Ela comeou a rodar as 22:22 e ainda est rodando. Deve terminar pelas 10 horas de hoje. Este foi o primeiro dos testes sugeridos que estou realizando e pelo visto est consumindo o tempo previsto (em funo do histrico do restore) e absurdo de 12 horas. O prximo teste que pretendo fazer trocar a clusula restrict por noaction conforme sugerido. Gente ... sei l ... mas esta constraint no est se comportando de forma minimamente razovel, realmente parece que h algum problema como os ndices existentes no estarem sendo usados, por exemplo. No tem jeito de saber o que o PG est fazendo? Como ele planeja a execuo desta constraint? Ser que os mantenedores no ficariam felizes de testar um caroo destes, isto claro, se no tiver nenhuma mancada no meio? Abraos e um bom e produtivo dia a todos. Sergio Medeiros Santi Leandro Damascena escreveu: Sergio Medeiros Santi escreveu: - Fernando. Na verdade a estrategia de backup funciona bem o problema o restore. Felizmente no tive a necessidade de restaurar foradamente o banco, s no consigo engolir que de 14 horas, 12 foram consumidas apenas por uma constraint. No me parece ser uma referncia circular porque o treco demora mas termina e nada registrado no log que pudesse me levar a acreditar nisto. O Fernando Saimon sugeriu voc criar a constraint primeiro e depois subir os dados para ver o resultado, voc fez isso? Se fez por favor desconsidere esse e-mail, apenas citei pois voc no explicou se fez ou no... Leandro Damascena ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral __ Informao do NOD32 IMON 2722 (20071214) __ Esta mensagem foi verificada pelo NOD32 sistema antivrus http://www.eset.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Acho que isso pode ser uma ajuda aumente o parametro maintenance_work_mem - Original Message - From: Fabio Telles [EMAIL PROTECTED] To: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Sent: Friday, December 14, 2007 8:22 AM Subject: Re: [pgbr-geral]Tempo excecivo ao restaurar banco - Mais alguém se habilita? Em 13/12/07, Sergio Medeiros Santi[EMAIL PROTECTED] escreveu: Pessoal, vou responder meu próprio e-mail para evitar responder um a um. Desde já o meu obrigado a todos. Eu particularmente gosto muito deste trabalho investigativo. Eu também! :-) Normalmente quando descobrimos o que houve percebemos que é possível usar a descoberta em outros pontos com expressivos resultados. Infelizmente o PG anda tem alguns mistérios a resolver. O principal deles é desenvolver um configurador que reuna informações sobre o hardware e sugira uma configuração razoável. Isto teria me ajudado bastante quando comecei com o PG. Pelo que olhei das apresentações do PGCon a coisa continua mais ou menos igual, não existe ciência nisto, mas alguma recomendações (poucas infelizmente). É meu caro... vida de DBA é difícil mesmo. Eu fico feliz por as coisas no PostgreSQL serem mais simples. O Oracle tem pelo menos o triplo de parâmetros documentados, fora uma miríade de parâmetros que só eles conhecem (medo!). Não há muito como fazer uma configurador automático confiável. Houve uma thread na lista pg_performance há uns meses atrás com um esquema para sugerir algumas configurações. Sei que o pessoal da SUN e da EnterpriseDB também está correndo atrás disso. Mas mesmo assim não é algo simples. Um bom DBA sempre vai fazer seus próprios testes e não irá nunca confiar num configurador automático. É claro que seria um bom ponto de partida ou algo melhor que nada para quem não tem experiência. Mas quando você tem um banco de dados maiores (em volume de dados, conexões ou complexidade de consultas), só mesmo um bom DBA salva a pátria. Nenhum fornecedor de SGDB conseguiu substituir a inteligência do DBA até hoje... e olhe que eles vivem tentando e prometendo isso! - Fábio. O autovacuum não é utilizado, mas diariamente é disparado um backup seguido de um vacuum analyse. Originalmente era usado o vacuum full, mas este foi abandonado porque em algumas oportundades ele não terminava e o banco ficava travado para os usuário no dia seguinte. O que tenho procurado fazer é um backup seguido de restore com alguma periodicidade. Alias é este procedimento que me fez questionar esta aplicação de constraint absurdamente lenta. Bom, uma vez que o autovacuum está desligado, mas você tem problemas com o vacuum full (que realmente não deve ser realizado com frequência), sugiro você exportar sua base, apagar o cluster inteiro, cria-lo novamente e importar o banco. É uma operação realmente delicada, mas se houver algum problema na estrutura de armazenamento, você deve resolver com isso. Espero que você tenha um ou mais discos/partições para seus dados. Se for o caso, bem, seria o caso de desmontar a partição e fazer uma varredura no disco (antes de recriar o cluster), só para ter certeza de que está tudo bem e você não tem nenhum bad block no caminho. Aliás, qual FS você está utilizando? Fez algum tuning no FS? Se o disco estiver ok, o cluster for novo e o import continuar demorando tudo isso... estará na hora de uma investigação realmente mais cuidadosa na sua estrutura de dados. Atenciosamente, Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] 25gb de imagem, isso presta?
Em 14/12/07, Leandro Damascena [EMAIL PROTECTED] escreveu: Paulo Saimon Ramos escreveu: sim, vai dar certo se sua itenção é destruir tua rede, micro e banco de dados. Que pergunta mais estúpida. ACHO que para o bem geral podemos discordar de pensamentos/idéias do próximo de uma forma mais produtiva (... educada ...) e manter o foco na solução/dúvida/idéia... :-D Leandro Damascena. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Leandro, como ja dito anteriormente, eu recomendo salvar o caminho do arquivo no banco, geralmente salvar arquivos costuma se desencorajado pela maioria dos DBA's, mas é claro que sempre há exceções. Num ambiente Cliente windows e servidor Linux por exemplo, não tenho idéia se isso é possivel. -- Roberto Baselio Lopes e-mail / Google Talk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] Curriculo: http://www2.curriculum.com.br/ucn/rbaselio ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Hot-Backup
Em 14/12/07, Malcus[EMAIL PROTECTED] escreveu: Bom Dia a todos. Primeiramente queria comentar o sucesso do PgConference e dar parabéns a todos que participaram do evento. Não sei se esta pergunta se encaixa nesta lista, porém estava tentando fazer hot-backup a partir dos arquivos WAL, utilizando o archive_command, porém jogando para um servidor backup também. O problema é o seguinte quando tentei iniciar o SBGD backup, ocorreu o seguinte erro: FATAL: incorrect checksum in control file Não basta copiar o Wall... você tem que copiar o control file também. Vide documentação: http://www.postgresql.org/docs/8.3/static/warm-standby.html Atenciosamente, Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] formatação_Moeda.
...obrigadU
2007/12/14, Julio Cesar Merenda Catardo [EMAIL PROTECTED]:
REPLACE(TRIM(TO_CHAR(CAMPO, REPLACE('99G999D99' ,'G', ' '))), ' ',
'.');
- ASSIM ESTÁ CORRETO.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
Marcelo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Hot-Backup
Bom Dia a todos. Primeiramente queria comentar o sucesso do PgConference e dar parabéns a todos que participaram do evento. Não sei se esta pergunta se encaixa nesta lista, porém estava tentando fazer hot-backup a partir dos arquivos WAL, utilizando o archive_command, porém jogando para um servidor backup também. O problema é o seguinte quando tentei iniciar o SBGD backup, ocorreu o seguinte erro: FATAL: incorrect checksum in control file Verifiquei as máquinas (não são superservidores) porém uma esta com processador Pentium 4 e a outra com Pentium 4 HT. Li que isso poderia ser problema entre arquitetura 32-bits e 64-bits. Teria alguma solução para contornar este problema? Obrigado Malcus ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Delphi/Zeos + PG + ByteA
Pessoal, alguem teria um exeplo de como cadastrar e recuperar uma imagem ou arquivo em um campo ByteA. Ja tentei de varias formas e ainda não achei um metodo que funcione. Ja pesquisei no google e nao achei nenhum exeplo. Obrigado. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Fbio! Pelos seus comentrios imagino que voc imagine que o postgres est rodando em linux, o que no verdade. Alias este um dos problema de se recortar uma mensagem. Detalhes relevantes acabam cortados. Tudos que citei at o momento est sendo testado em W2K. Notei esta demora quando em uma manuteno preventiva, fiz um backup, dropei o banco e fiz o restore. A pesar do banco ser grande achei o tempo de restore demasiado grande. A partir da comecei a realizar testes em um servidor backup que no est em produo, com isso tenho a certeza de que nenhum outro processo o est acessando. Como testei em dois servidores com processadores, memria e disco distintos no acredito que o problema advenha de alguma falha fsica. Inclusive o servidor em produo um dual xeon, 4G, SAS e o backup um xeon, 2G, SAS e diferena entre eles no tempo total de execuo inferior a 10%. Eu particularmente suspeito que ou uma mancada minha ou do postgres est sendo exercitado em algum ponto cego e desconhecido que produz esta preformance incompatvel com o banco. Se ele levasse 85% do tempo total para criar um ndice eu at poderia engolir, mas para aplicar uma constraint que relaciona um campo que possui ndice com outro que chave primria ... t difcil. Mas ainda tenho testes a realizar ... espero, em breve, dar notcias conclusiva. Como eu, no desanimem, e continuem enviando sugestes. Abraos, Sergio Medeiros Santi Fabio Telles escreveu: Em 13/12/07, Sergio Medeiros Santi[EMAIL PROTECTED] escreveu: Pessoal, vou responder meu prprio e-mail para evitar responder um a um. Desde j o meu obrigado a todos. Eu particularmente gosto muito deste trabalho investigativo. Eu tambm! :-) Normalmente quando descobrimos o que houve percebemos que possvel usar a descoberta em outros pontos com expressivos resultados. Infelizmente o PG anda tem alguns mistrios a resolver. O principal deles desenvolver um configurador que reuna informaes sobre o hardware e sugira uma configurao razovel. Isto teria me ajudado bastante quando comecei com o PG. Pelo que olhei das apresentaes do PGCon a coisa continua mais ou menos igual, no existe cincia nisto, mas alguma recomendaes (poucas infelizmente). meu caro... vida de DBA difcil mesmo. Eu fico feliz por as coisas no PostgreSQL serem mais simples. O Oracle tem pelo menos o triplo de parmetros documentados, fora uma mirade de parmetros que s eles conhecem (medo!). No h muito como fazer uma configurador automtico confivel. Houve uma thread na lista pg_performance h uns meses atrs com um esquema para sugerir algumas configuraes. Sei que o pessoal da SUN e da EnterpriseDB tambm est correndo atrs disso. Mas mesmo assim no algo simples. Um bom DBA sempre vai fazer seus prprios testes e no ir nunca confiar num configurador automtico. claro que seria um bom ponto de partida ou algo melhor que nada para quem no tem experincia. Mas quando voc tem um banco de dados maiores (em volume de dados, conexes ou complexidade de consultas), s mesmo um bom DBA salva a ptria. Nenhum fornecedor de SGDB conseguiu substituir a inteligncia do DBA at hoje... e olhe que eles vivem tentando e prometendo isso! - Fbio. O autovacuum no utilizado, mas diariamente disparado um backup seguido de um vacuum analyse. Originalmente era usado o vacuum full, mas este foi abandonado porque em algumas oportundades ele no terminava e o banco ficava travado para os usurio no dia seguinte. O que tenho procurado fazer um backup seguido de restore com alguma periodicidade. Alias este procedimento que me fez questionar esta aplicao de constraint absurdamente lenta. Bom, uma vez que o autovacuum est desligado, mas voc tem problemas com o vacuum full (que realmente no deve ser realizado com frequncia), sugiro voc exportar sua base, apagar o cluster inteiro, cria-lo novamente e importar o banco. uma operao realmente delicada, mas se houver algum problema na estrutura de armazenamento, voc deve resolver com isso. Espero que voc tenha um ou mais discos/parties para seus dados. Se for o caso, bem, seria o caso de desmontar a partio e fazer uma varredura no disco (antes de recriar o cluster), s para ter certeza de que est tudo bem e voc no tem nenhum bad block no caminho. Alis, qual FS voc est utilizando? Fez algum tuning no FS? Se o disco estiver ok, o cluster for novo e o import continuar demorando tudo isso... estar na hora de uma investigao realmente mais cuidadosa na sua estrutura de dados. Atenciosamente, Fbio Telles ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Hot-Backup
2007/12/14, Malcus [EMAIL PROTECTED]: Primeiramente queria comentar o sucesso do PgConference e dar parabéns a todos que participaram do evento. Obrigado pela parte que me cabe! ;-) Não sei se esta pergunta se encaixa nesta lista Sim! estava tentando fazer hot-backup a partir dos arquivos WAL, utilizando o archive_command, porém jogando para um servidor backup também. O problema é o seguinte quando tentei iniciar o SBGD backup, ocorreu o seguinte erro: FATAL: incorrect checksum in control file Verifiquei as máquinas (não são superservidores) porém uma esta com processador Pentium 4 e a outra com Pentium 4 HT. Li que isso poderia ser problema entre arquitetura 32-bits e 64-bits. Teria alguma solução para contornar este problema? O HT não faz diferença, mas a arquitetura sim. Arquivos binários de dados são incompatíveis entre arquiteturas. Ou você usa dois servidores da mesma arquitetura, ou cópia lógica em vez de física. -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Alteração do postgresql.conf
RFC 1855, netiqueta: mensagens em texto simples (não HTML) por favor. 2007/12/14, Julio Cesar Merenda Catardo [EMAIL PROTECTED]: Não estou conseguindo alterar os parâmetros no postgresql.conf : Mensagens de erro? LC_MONERATY = 'pt_BR' MONETARY? -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Sergio Medeiros Santi wrote: - Luiz. Estou usando 32M em shared_buffers e 16M em maintenance_work_mem. 32M de shared_buffers? Isso é muito pequeno. Experimente 25% da RAM. Mas isso não vem ao caso com relação a restauração. 16M de maintenance_work_mem? Isto é muito pequeno. Experimente usar de 10 a 30% da RAM. Em restaurações é recomendado aumentar esse valor para diminuir o tempo de restauração pois essa fatia da memória é utilizada pelo VACUUM, CREATE INDEX, ALTER TABLE foo ADD FOREIGN KEY. Se não resolver, podes me enviar em privado o esquema das duas tabelas envolvidas com os respectivos CREATE INDEX, ALTER TABLE foo ADD FOREIGN KEY. Ajudaria se eu pudesse saber o postgresql.conf que está utilizando. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - Mais a lguém se habilita?
Em 13/12/07, Sergio Medeiros Santi[EMAIL PROTECTED] escreveu: Pessoal, vou responder meu próprio e-mail para evitar responder um a um. Desde já o meu obrigado a todos. Eu particularmente gosto muito deste trabalho investigativo. Eu também! :-) Normalmente quando descobrimos o que houve percebemos que é possível usar a descoberta em outros pontos com expressivos resultados. Infelizmente o PG anda tem alguns mistérios a resolver. O principal deles é desenvolver um configurador que reuna informações sobre o hardware e sugira uma configuração razoável. Isto teria me ajudado bastante quando comecei com o PG. Pelo que olhei das apresentações do PGCon a coisa continua mais ou menos igual, não existe ciência nisto, mas alguma recomendações (poucas infelizmente). É meu caro... vida de DBA é difícil mesmo. Eu fico feliz por as coisas no PostgreSQL serem mais simples. O Oracle tem pelo menos o triplo de parâmetros documentados, fora uma miríade de parâmetros que só eles conhecem (medo!). Não há muito como fazer uma configurador automático confiável. Houve uma thread na lista pg_performance há uns meses atrás com um esquema para sugerir algumas configurações. Sei que o pessoal da SUN e da EnterpriseDB também está correndo atrás disso. Mas mesmo assim não é algo simples. Um bom DBA sempre vai fazer seus próprios testes e não irá nunca confiar num configurador automático. É claro que seria um bom ponto de partida ou algo melhor que nada para quem não tem experiência. Mas quando você tem um banco de dados maiores (em volume de dados, conexões ou complexidade de consultas), só mesmo um bom DBA salva a pátria. Nenhum fornecedor de SGDB conseguiu substituir a inteligência do DBA até hoje... e olhe que eles vivem tentando e prometendo isso! - Fábio. O autovacuum não é utilizado, mas diariamente é disparado um backup seguido de um vacuum analyse. Originalmente era usado o vacuum full, mas este foi abandonado porque em algumas oportundades ele não terminava e o banco ficava travado para os usuário no dia seguinte. O que tenho procurado fazer é um backup seguido de restore com alguma periodicidade. Alias é este procedimento que me fez questionar esta aplicação de constraint absurdamente lenta. Bom, uma vez que o autovacuum está desligado, mas você tem problemas com o vacuum full (que realmente não deve ser realizado com frequência), sugiro você exportar sua base, apagar o cluster inteiro, cria-lo novamente e importar o banco. É uma operação realmente delicada, mas se houver algum problema na estrutura de armazenamento, você deve resolver com isso. Espero que você tenha um ou mais discos/partições para seus dados. Se for o caso, bem, seria o caso de desmontar a partição e fazer uma varredura no disco (antes de recriar o cluster), só para ter certeza de que está tudo bem e você não tem nenhum bad block no caminho. Aliás, qual FS você está utilizando? Fez algum tuning no FS? Se o disco estiver ok, o cluster for novo e o import continuar demorando tudo isso... estará na hora de uma investigação realmente mais cuidadosa na sua estrutura de dados. Atenciosamente, Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] 25gb de imagem, isso presta?
Em 13/12/07, Paulo Saimon Ramos[EMAIL PROTECTED] escreveu: sim, vai dar certo se sua itenção é destruir tua rede, micro e banco de dados. Que pergunta mais estúpida. Caro Saimon... a pergunta não é nada estúpida. Gostaria que você se colocasse de forma mais adequada na lista. Você não está agregando valor para os assinantes da lista com este tipo de resposta. Tecnicamente a pergunta do nosso colega faz todo o sentido. Não conheço o contexto exato mas veja, o assunto é tão relevante que um dos nossos desenvolvedores nacionais escolheu este tema para dar uma palestra no pgcon. Tenho certeza que o Sr. Diogo Biazus tem conhecimento de sobra para abordar vários outros assuntos. Escolheu este pois achou relevante. Uma curiosidade para quem não estava no pgcon: uma pessoa da platéia platéia perguntou para o Diogo como proceder no caso dele. Ele tem inúmeras fotos de satélite com cerga de 2GB cada. Algumas consultas juntam várias fotos totalizando mais de 200GB. Como você pode var Saimon, quando a demanda existe, temos que buscar a solução. No caso das fotos de satélite, não se trata de uma demanda nada trivial. Com certeza eles não usam uma rede qualquer para isso. Estamos falando de aplicações de ponta. Pode ser uma exceção, mas enfim... pode acontecer. Atenciosamente, Fábio Telles -- blog: http://www.midstorm.org/~telles/ e-mail / jabber: [EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Altera��o do postgresql.conf
LATIN1 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Padrões de nomenclatura
Patrick Espake wrote: Bom dia a todos, Sou novo em PostgreSQL, estou criando um banco de dados e preciso definir um padrão de nomenclatura para tabelas, índices, constraints, domains, functions, sequences, triggers e o mais o que for necessário. Alguém possui um exemplo de nomenclatura? Ou poder me dar um exemplo? Utilizamos o seguinte: tabela: qualquer nome campo: identificação_do_tipo_qq_nome indice: i_tabela_campos constraints: unique: un_campos check: ck_nome_da_regra function: sp_funcionalidade view: vw_nome_idenficação trigger: ai o caso é mais sério. inicia com tr_localevento_nome local seria B para before e A para after evento seria I - insert / U - update / D - delete. podem ser um ou os 3 juntos. Isso facilita pq apenas olhando para o nome da trigger você já sabe como ela é executada. Isso é regra de nomenclatura que utilizo aqui. Cada um tem a sua. Espere para ver o que os outros sugerem e cria a sua do jeito que achar mais fácil Att Evandro ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Res: Delphi/Zeos + PG + ByteA
Usando Zeos é moleza, é só vc fazer um SaveToFile, como se o campo do BD, fosse um diretório do sistema. Vinicius - Msi Soluções www.msisolucoes.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Memory storage on PostgreSQL
Caros Achei interessante esse artigo, alguém já fez isso? http://www.redhatmagazine.com/2007/12/12/tip-from-an-rhce-memory-storage-on-postgresql/ []s Bene -- Benedito A. Cruz Centro de Referência em Informação Ambiental - CRIA email [EMAIL PROTECTED] fone 55 19 3288 0466 begin:vcard fn:Benedito A. Cruz n:Cruz;Benedito A. email;internet:[EMAIL PROTECTED] version:2.1 end:vcard ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Padrões de nomenclatura
2007/12/14, Patrick Espake [EMAIL PROTECTED]: Sou novo em PostgreSQL, estou criando um banco de dados e preciso definir um padrão de nomenclatura para tabelas, índices, constraints, domains, functions, sequences, triggers e o mais o que for necessário. Alguém possui um exemplo de nomenclatura? Ou poder me dar um exemplo? Tabelas normalmente são substantivos, só definir se plural (que eu acho conveniente) ou singular (mais conciso). Domínios e funções idem, mas sempre no singular. Os outros objetos são normalmente pre- ou posfixados com um indicador do tipo de objeto, pela ordem acima: ix pk uk sq tg Estou pensando em converter um documento meu para LaTeX e publicá-lo. -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Sergio Medeiros Santi escreveu: Não testei o -1 não, mas que mal le pergunte, aplicar uma constraint gera alguma atualização ou apenas valida a restrição? Abraços, Sergio Medeiros Santi Osvaldo Rosario Kussama escreveu: Ninguém comentou mas você tentou utilizar a opção -1 (ou --single-transaction)? http://www.postgresql.org/docs/8.2/interactive/app-pgrestore.html Creio que esta opção agiliza o processo como um todo. Especificamente para a restrição de integridade já sugeriram que você ajustasse o maintenance_work_mem. Em: http://www.powerpostgresql.com/Downloads/annotated_conf_80.html existe o seguinte comentário: Specifies the maximum amount of memory to be used in maintenance operations, such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. The value is specified in kilobytes, and defaults to 16384 kilobytes (16 MB). Since only one of these operations can be executed at a time by a database session, and an installation normally doesn't have very many of them happening concurrently, it's safe to set this value significantly larger than work_mem. Larger settings may improve performance for vacuuming and for restoring database dumps. Formerly vacuum_mem. Renamed to reflect its expanded role in allocating memory for index loads. The default for this is generally too low, and will result in VACUUMs and index creation tying up the system I/O and/or object locks while it swaps memory. Good settings are generally 32MB to 256MB; it depends on both the RAM you have available and the size of your largest (expected) database objects. Like work_mem, can be allocated at runtime so you can increase it temporarily for loading indexes/creating keys on very large tables. 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] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Sergio Medeiros Santi escreveu: Não testei o -1 não, mas que mal le pergunte, aplicar uma constraint gera alguma atualização ou apenas valida a restrição? Abraços, Sergio Medeiros Santi Osvaldo Rosario Kussama escreveu: Ninguém comentou mas você tentou utilizar a opção -1 (ou --single-transaction)? http://www.postgresql.org/docs/8.2/interactive/app-pgrestore.html Complementando: Você também pode colocar fsync como off (com os devidos cuidados). 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] 25gb de imagem, isso presta?
Conforme comentei no PG Con, eu armazeno apenas o PATH. Na verdade são imagens de produtos e nem sequer há um campo pra PATH em cada imagem, mas sim por servidor; o nome das imagens sempre é o código adicionado à extensão .jpg e o sistema monta o PATH sozinho. Por exemplo, no servidor PG em 10.10.0.2 o campo PATH é imagens, o servidor de imagens é 10.10.0.4. O PATH da imagem do produto 1234 fica http://10.10.0.4/imagens/1234.jpg; com tudo em minúsculas. Isso permite que o servidor das imagens seja independente do servidor do BD. Além disso, outras pessoas (pessoal do marketing, compras, etc) podem colocar as imagens no diretório correspondente (do Apache) de forma transparente para o DBA. Na hora de exibir uma imagem, se o arquivo não for encontrado no servidor web é exibida a mensagem Sem imagem. Em 14/12/07, Roberto Baselio Lopes [EMAIL PROTECTED] escreveu: Em 14/12/07, Leandro Damascena [EMAIL PROTECTED] escreveu: Paulo Saimon Ramos escreveu: sim, vai dar certo se sua itenção é destruir tua rede, micro e banco de dados. Que pergunta mais estúpida. ACHO que para o bem geral podemos discordar de pensamentos/idéias do próximo de uma forma mais produtiva (... educada ...) e manter o foco na solução/dúvida/idéia... :-D Leandro Damascena. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Leandro, como ja dito anteriormente, eu recomendo salvar o caminho do arquivo no banco, geralmente salvar arquivos costuma se desencorajado pela maioria dos DBA's, mas é claro que sempre há exceções. Num ambiente Cliente windows e servidor Linux por exemplo, não tenho idéia se isso é possivel. -- Roberto Baselio Lopes e-mail / Google Talk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] Curriculo: http://www2.curriculum.com.br/ucn/rbaselio ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente, Alexsander da Rosa Linux User #113925 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Tempo excecivo ao restaurar banco - M ais alguém se habilita?
Euler: Estou esperando terminar meu teste anterior onde dropei a constraint com restrict e estou aplicando com no action, mas como j est rodando a 4 horas estou acreditando que conforme o previsto no vai fazer muita diferena no. Com relao a tua colaborao e como esto testando em um servidor backup com 2G, enquanto o de produo tem 4G, vou colocar shared_buffers e maintenence_work_mem em 500M. Acredito que esta reconfigurao deva melhorar o tempo total do restore, mas custo a crer que isto v melhorar alguma coisa na tal constraint. Bom depois eu conto o resultado. Quanto a te enviar os esquemas no tem problema, mas vou esgotar mais um pouco meus neurnios antes de consumir os teus. Um grande abrao, Sergio Medeiros Santi Euler Taveira de Oliveira escreveu: Sergio Medeiros Santi wrote: - Luiz. Estou usando 32M em shared_buffers e 16M em maintenance_work_mem. 32M de shared_buffers? Isso muito pequeno. Experimente 25% da RAM. Mas isso no vem ao caso com relao a restaurao. 16M de maintenance_work_mem? Isto muito pequeno. Experimente usar de 10 a 30% da RAM. Em restauraes recomendado aumentar esse valor para diminuir o tempo de restaurao pois essa fatia da memria utilizada pelo VACUUM, CREATE INDEX, ALTER TABLE foo ADD FOREIGN KEY. Se no resolver, podes me enviar em privado o esquema das duas tabelas envolvidas com os respectivos CREATE INDEX, ALTER TABLE foo ADD FOREIGN KEY. Ajudaria se eu pudesse saber o postgresql.conf que est utilizando. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Altera��o do postgresql.conf
Eu escrevi errado É LC_MONETARY = 'pt_BR' ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Padrões de nomenclatura
2007/12/14, Fernando Brombatti [EMAIL PROTECTED]: as tabelas usam o prefixo do sistema, tipo ctb_, rh_ Faz isso não, Fernando… já pensou numa reorganização do sistema? Para isso, use esquemas. Muito mais flexível. -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Memory storage on PostgreSQL
Benedito A. Cruz escreveu: Caros Achei interessante esse artigo, alguém já fez isso? http://www.redhatmagazine.com/2007/12/12/tip-from-an-rhce-memory-storage-on-postgresql/ Já sim mas com outra solução, porém a mesma abordagem. Tenho 1 sistema rodando que monta um TABLESPACE no /dev/shm para tabelas que contém dados que são necessários APENAS quando o sistema está em execução, mas você tem que tomar alguns cuidados com isso... Vou falar da experiência que eu tive e segue os problemas ocorridos: Problemas: 1 - Espaço: chegou um ponto da aplicação que ela começou a consumir muito espaço fazendo com que entrasse em concorrência com os processos do SO e travasse a máquina, então montei uma partição com 30% do espaço total da memória e otimizei algumas estrutura de tabela no banco visando limpar dados desnecessários. APESAR de que eu recomendaria o uso dessa solução apenas para tabelas onde houvessem MUITO MAIS consulta do que inserção/atualização, mas para adequar ao meu problema tive que usar de outra forma. 2 - Reboot: apesar de não ser dados críticos para o sistema, quando o sistema reboota ou demontamos a partição, TODOS os dados são perdidos e isso pode te gerar problemas dependendo do tipo de dados que você armazenou lá. Ganho: 1 - Performance: é absurdamente maior a performance que você tem salvando dados na memória, principalmente se você vai usar muita consulta Essa explicação eu trouxe muito para a experiência que eu tive com esse uso, se alguém mais usou de uma outra forma ou tem mais dicas em cima dessa abordagem, seria legal contribuir, é um tópico interessante e muitas vezes pouco usado. Leandro Damascena. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Alteração do postgresql.conf
Subiu agora? 2007/12/14, Julio Cesar Merenda Catardo [EMAIL PROTECTED]: Eu escrevi errado É LC_MONETARY = 'pt_BR' ___ 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] Nao sei como responder no forum ...
Pessoal, quando desejo responder a um determinado assunto, como devo proceder? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] 25gb de imagem, isso presta?
Este o mesmo mtodo que utilizo, s que acrescento um sufixo _x onde x o nmero de ordem da foto. Assim posso ter quantas fotos quizer para cada produto e ainda dizer em que ordem quero que apaream. Sergio Medeiros Santi Alexsander Rosa escreveu: Conforme comentei no PG Con, eu armazeno apenas o PATH. Na verdade so imagens de produtos e nem sequer h um campo pra PATH em cada imagem, mas sim por servidor; o nome das imagens sempre o cdigo adicionado extenso .jpg e o sistema monta o PATH sozinho. Por exemplo, no servidor PG em 10.10.0.2 o campo PATH "imagens", o servidor de imagens "10.10.0.4". O PATH da imagem do produto 1234 fica " http://10.10.0.4/imagens/1234.jpg" com tudo em minsculas. Isso permite que o servidor das imagens seja independente do servidor do BD. Alm disso, outras pessoas (pessoal do marketing, compras, etc) podem colocar as imagens no diretrio correspondente (do Apache) de forma transparente para o DBA. Na hora de exibir uma imagem, se o arquivo no for encontrado no servidor web exibida a mensagem "Sem imagem". Em 14/12/07, Roberto Baselio Lopes [EMAIL PROTECTED] escreveu: Em 14/12/07, Leandro Damascena [EMAIL PROTECTED] escreveu: Paulo Saimon Ramos escreveu: sim, vai dar certo se sua iteno destruir tua rede, micro e banco de dados. Que pergunta mais estpida. ACHO que para o bem geral podemos discordar de pensamentos/idias do prximo de uma forma mais produtiva (... educada ...)e manter o foco na soluo/dvida/idia... :-D Leandro Damascena. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Leandro, como ja dito anteriormente, eu recomendo salvar o caminho do arquivo no banco, geralmente salvar arquivos costuma se desencorajado pela maioria dos DBA's, mas claro que sempre h excees. Num ambiente Cliente windows e servidor Linux por exemplo, no tenho idia se isso possivel. -- Roberto Baselio Lopes e-mail / Google Talk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] Curriculo: http://www2.curriculum.com.br/ucn/rbaselio ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente, Alexsander da Rosa Linux User #113925 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral __ Informao do NOD32 IMON 2724 (20071214) __ Esta mensagem foi verificada pelo NOD32 sistema antivrus http://www.eset.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Dúvida vacuum - PG 8.3
Boa tarde a todos, Tenho uma dúvida quanto a implementação do vacuum na versão 8.3. Lendo na documentação vi que agora vários processos de vacuum vão rodar concorrentemente para que seja mais rápido tal processo, só que, esses múltiplos processos vão se basear na leitura dos datafile ou dos objetos do banco (tabelas/indices)?? Isso não ficou muito claro na palestra do David Fetter que rolou no PGCon. Vou expor o problema para que sugestões/idéias possam ser repassados. Estou desenvolvendo um sistema de tracking e fazendo alguns testes iniciais de carga vimos que teremos tabelas diarias com média de 30MM de registros e com 10GB. Para esta solução usarei tabelas particionadas (criadas com INHERITS a partir de uma pai) e vou gravando os dados diários nessas tabelas por um périodo de dois meses (depois movo pra arquivo morto), só que nesse período precisarei do banco voando e para isso terei que contar com meu amigo vacuum para dar uma mãozinha. Em experiências anteriores com um FS muito grande o vacuum chegou a demorar 1 dia para rodar, isso porque desabilitei o auto vacuum que me gerava um load animal na máquina, então, a minha idéia inicial foi: Caso o vacuum da versão 8.3 se baseie nos datafile e não nos objetos (assumi isso e nivelei por baixo) crio 2 FileSystem (1 tables e 1 indexs) a cada dia e crio TABLESPACE em cima desses FS e crio toda a estrutura de tabelas compartilhadas em cima desses TABLESPACE. Agendaria processos no servidor para passar o vacuum full em tabelas DIA-1 (dia anterior), o que me daria mais performance já que o número de datafile que o vacuum teria que varrer seria MUITO menor e o SO controlaria para mim o buffer e a fila de i/o de cada FS independente e não teria problemas de ter lock na tabela, já que ela foi rotacionada. Só que isso demanda um sincronismo MUITO redondo por parte das aplicações para que não zoem minha tabela do fstab outras coisas e eu teria que correr esse risco. Vocês teriam alguma outra idéia, solução? Obrigado. Leandro Damascena. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Descobrir Tabelas
2007/12/14, Carla Mazzi [EMAIL PROTECTED]: Gostaria de uma ajuda, estou precisando descobrir em quais bancos de dados eu possuo determinada tabela, existe algum comando para fazer isso? Carla, dê uma olhada no esquema de informações (information_schema). -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Descobrir Tabelas
2007/12/14, Carla Mazzi [EMAIL PROTECTED]: Gostaria de uma ajuda, estou precisando descobrir em quais bancos de dados eu possuo determinada tabela, existe algum comando para fazer isso? Carla, dê uma olhada no esquema de informações (information_schema). -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Descobrir Tabelas
Na tabela pg_class vc consegue. On Dec 14, 2007 2:29 PM, Carla Mazzi [EMAIL PROTECTED] wrote: Boa Tarde! Gostaria de uma ajuda, estou precisando descobrir em quais bancos de dados eu possuo determinada tabela, existe algum comando para fazer isso? Desde já obrigada. -- Carla Mazzi e-mail: [EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Fernando Brombatti email-msn-gtalk-skype: [EMAIL PROTECTED] work: +55 54 3218-6060 mobile: +55 54 8112-7250 Visite www.datamais.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Exclusão da lista
Boa noite!! Gostaria de saber como faço para excluir o meu e-mail desta lista!! Aguardo!! - Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Descobrir Tabelas
Carla Mazzi escreveu: Boa Tarde! Gostaria de uma ajuda, estou precisando descobrir em quais bancos de dados eu possuo determinada tabela, existe algum comando para fazer isso? Oi Carla, veja se este select te atende SELECT n.nspname, c.relname, a.attname, format_type(t.oid, null) AS typname FROM pg_namespace n, pg_class c, pg_attribute a, pg_type t WHERE n.oid = c.relnamespace AND c.relkind = 'r' -- sem ndices AND n.nspname not like 'pg\\_%' -- sem catlogos AND n.nspname != 'information_schema' -- sem information_schema AND a.attnum 0 -- sem atributo de sistema AND not a.attisdropped -- sem colunas removidas AND a.attrelid = c.oid AND a.atttypid = t.oid ORDER BY nspname, relname, attname Desde j obrigada. Marcelo. -- Carla Mazzi e-mail: [EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Descobrir Tabelas
Carla Mazzi escreveu: Boa Tarde! Gostaria de uma ajuda, estou precisando descobrir em quais bancos de dados eu possuo determinada tabela, existe algum comando para fazer isso? Desde j obrigada. Apenas complementando voc pode ver o link abaixo de onde retirei o comando: http://pgdocptbr.sourceforge.net/pg80/catalogs.html -- Carla Mazzi e-mail: [EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] 25gb de imagem, isso presta?
2007/12/14, Alexsander Rosa [EMAIL PROTECTED]: Por exemplo, no servidor PG em 10.10.0.2 o campo PATH é imagens, o servidor de imagens é 10.10.0.4. O PATH da imagem do produto 1234 fica http://10.10.0.4/imagens/1234.jpg; com tudo em minúsculas. Nota aos incautos: o uso de IP pode causar danos à saúde. A recomendação é nunca usar endereços IP, mas um apelido DNS designando um serviço, apontando para o nome do hospedeiro. -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] 25gb de imagem, isso presta?
O legal da modelagem que usei é que no BD tudo são strings e o usuário e/ou o sysadmin podem colocar o conteúdo que quiserem nos campos, seja na forma de IP, seja na forma de um dns alias... para o DBA e para o programador isso tudo é transparente. :-) Em 14/12/07, Leandro DUTRA [EMAIL PROTECTED] escreveu: 2007/12/14, Alexsander Rosa [EMAIL PROTECTED]: Por exemplo, no servidor PG em 10.10.0.2 o campo PATH é imagens, o servidor de imagens é 10.10.0.4. O PATH da imagem do produto 1234 fica http://10.10.0.4/imagens/1234.jpg; com tudo em minúsculas. Nota aos incautos: o uso de IP pode causar danos à saúde. A recomendação é nunca usar endereços IP, mas um apelido DNS designando um serviço, apontando para o nome do hospedeiro. -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente, Alexsander da Rosa Linux User #113925 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Nao sei como responder no forum ...
2007/12/14, Claudio Rogerio Carvalho Filho [EMAIL PROTECTED]: Pessoal, quando desejo responder a um determinado assunto, como devo proceder? Desta maneira! Ou a dúvida era outra? -- +55 (11) 5685 2219 xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 ICQ/AIM: aim:GoIM?screenname=61287803 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Padrões de nomenclatura
Patrick Espake escreveu:
Bom dia a todos,
Sou novo em PostgreSQL, estou criando um banco de dados e preciso
definir um padrão de nomenclatura para tabelas, índices, constraints,
domains, functions, sequences, triggers e o mais o que for necessário.
Alguém possui um exemplo de nomenclatura? Ou poder me dar um exemplo?
Por mais que várias pessoas odeiem e isso seja redudante em níveis
eleveados, eu sempre uso o seguinte padrão:
-- CRIANDO A TABLE
CREATE TABLE tb_APLICACAO_NOMETABELA ( -- APLICACAO e NOMETABELA em
minusculo e singular.
nometabelacampo NUMERIC(1)
);
-- Exemplo: CREATE TABLE tb_firefs_usuario ( usuarioid NUMERIC(1) NOT
NULL );
-- CRIANDO A PK
ALTER TABLE tb_aplicacao_nometabela ADD CONSTRAINT
pk_aplicacao_nometabela_nomecampo PRIMARY KEY (nomecampo);
-- Exemplo: ALTER TABLE tb_firefs_usuario ADD CONSTRAINT
fk_firefs_usuario_usuarioid PRIMARY KEY (usuarioid);
-- CRIANDO OUTRA TABLE
CREATE TABLE tb_firefs_detalheusuario (
detalheusuarioid NUMERIC(1) NOT NULL,
usuario_usuarioid NUMERIC(1) NOT NULL
);
-- CRIANDO A PK
ALTER TABLE tb_firefs_detalheusuario ADD CONSTRAINT
pk_firefs_detalheusuario_detalheusuarioid PRIMARY KEY (detalheusuarioid);
--CRIANDO A FK
ALTER TABLE tb_firefs_detalheusuario ADD CONSTRAINT
fk_firefs_detalheusuario_usuario_usuarioid FOREIGN KEY
(usuario_usuarioid) REFERENCES tb_firefs_usuario (usuarioid);
-- CRIANDO SEQUENCE
CREATE SEQUENCE sq_firefs_usuario START 1;
--CRIANDO TYPES
CREATE TYPE ty_status AS ENUM ('ATIVO','CANCELADO');
--CRIANDO FUNCTIONS
CREATE FUNCTION fu_busca_usuario(text) RETURNS text
Te digo que já tive vários quebra pau com vários desenvolvedores e
dbas que falavam que isso era redundante demais e ocupava mais código,
porém quando bato o olho em uma estrutura consigo identificar
imediatamente o que é cada coisa e já convenci muita gente a usar esse
padrão de nomeclatura.
Leandro Damascena.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] 25gb de imagem, isso presta?
Alexsander Rosa escreveu: O legal da modelagem que usei é que no BD tudo são strings e o usuário e/ou o sysadmin podem colocar o conteúdo que quiserem nos campos, seja na forma de IP, seja na forma de um dns alias... para o DBA e para o programador isso tudo é transparente. :-) Mas o que o Leandro Dutra pediu cuidado não foi com a modelagem e sim pelo fato de você colocar IP no PATH e não nome (DNS), amanhã a máquina que mora esses arquivos precisar trocar o IP e lá vai você correr atrás para dar UPDATE nesses registros para garantir o funcionamento da aplicação... Problema esse que você poderia ter evitado criando uma entrada no DNS ou uma tabelinha de alias para IP-NOME... E te falar, já vi isso acontecer e foi um desespero para atualizar todos os registros e não comprometer a aplicação... Leandro Damascena. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Nao sei como responder no forum ...
--- Claudio Rogerio Carvalho Filho [EMAIL PROTECTED] escreveu: Pessoal, quando desejo responder a um determinado assunto, como devo proceder? Se você recebe as mensagens individualmente é só responder a mensagem desejada. Se você recebe as mensagens em modo digest convém manter apenas a mensagem a que está repondendo e apagar todas as demais. De preferência não utilizar top-posting e enviar suas mensagens em texto puro (não utilizar html). Osvaldo Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
