[pgbr-geral] You're invited
Comunidade, Please connect with me on Naymz. This invitation will expire in 30 days. - Leandro Dutra https://www.naymz.com/login/handle_invite.action?emailMessage.uid=013f-19d7-92d0-0767-7831b86cdcb8 Naymz | 8340 Lincoln Ave Ste 116 | Skokie | IL | 60077 Stop receiving all Naymz email: https://www.naymz.com/unsubscribe.action?emailMessage.uid=013f-19d7-92d0-0767-7831b86cdcb8___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] NoSQL
Colega, por favor, siga a RFC 1855. Não responda no topo, não inclua citações irrelevantes no fim, mude o assunto para ser relevante. Le 2012-9-22 11h2, Fábio Hentz Lunkes a écrit : Pessoal, entendo que NoSQL seja um projeto imaturo. Não é um projeto, e é prerrelacional (cerca de meio século). Representar as entidades do sistema em objetos em em uma camada inferior mapea-los para tabelas, é a superação em administrar ineficientemente os recursos computacionais disponíveis. Não entendi… superação em administrar ineficientemente? Algum anglicismo? 4) Tipos de dados ricos, é ter a possibilidade de um grande variedade de representar os dados na memória de forma diferente, mas tendo o mesmo significado. Não, essa é a distinção entre forma de armazenamento e possíveis representações. Não sei como está a possibilidade dessa distinção em ISO SQL ou no PostgreSQL. Agora, não entendi porque levantaste o assunto NoSQL… -- 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] Substituição dos ORM
Le 2012-9-12 16h37, Eden Cardim a écrit : Meta-resposta: Existe padrão de resposta de email sancionado por alguma organização relevante? RFC 1855 e outros que me fogem à memória… Certo, porém acrescentar novos tipos ou alterar os existentes sem downtime da base costuma, na minha experiência, ser administrativamente mais custoso do que atualizar código numa aplicação desacoplada. Por outro lado, as inconsistências causadas por atualizações que passam por fora das regras que estão nas aplicações também… GF Não mesmo. Não entendi porque a base teria de gerar o SVG quando os GF dados do grafo estão na base. Porque alguém precisa dos dados em forma de SVG, logo, alguma parte do sistema precisa transformar o grafo armazenado em relações num documento SVG. E não é trivial realizar essa transformação usando SQL E isso não tem nada a ver com o que discutimos, uma vez que a transformação não tem nada a ver nem com o modelo relacional, nem com orientação a objetos. é menos trivial usar SQL para produzir um formato intermediário e depois converter esse formato no produto final (o SVG). É nessa transformação que um ORM (sic) é útil. E esse ‘sic’ aí mostra que estás forçando o termo. O que só está gerando confusão, e não contribui para a discussão. Use as bibliotecas que quiser, faça as transformações que quiser, mas isso não é mapeamento objeto-relacional. GF Ainda não as encontrei por parte de quem conheça o modelo relacional. GF Normalmente quem controverte mal conhece SQL — conhece no máximo como GF programador, não como modelo de dados. 3 falácias retóricas na mesma sentença, assim fica difícil… Permance o fato: é controverso. Precisas demonstrá-las. Mas não são falácias, são a experiência. Duas décadas dela. GF Até aí morreu o Neves. Novamente, qual o problema de transformar os GF dados fora da base? Isso nada tem a ver com as regras organizacionais GF (‘de negócio’), ou com o mapeamento OR. Discordo, tem tudo a ver, porque quando se desenvolve orientado a objetos você precisa de um ponto de entrada dos dados no seu modelo OO E o que isso tem a ver com essa transformação? Ou boiei… de uma forma ou de outra. Se você vai fazer isso manualmente ou não é uma outra questão, mas o mapeamento está sempre presente, usando ORM (sic) ou não. O problema está na forma como os ORM (sic) mais conhecidos abstraem essa transformação, mas é perfeitamente possível existirem abstrações razoáveis pra esse tipo de operação. Tu teimas em chamar meras transformações em mapeamento. Aí não dá para discutir, por simples falta de sentido quando se dá aos termos o significado que bem se entende, e não o convencional. Veja, se chamas qualquer biblioteca de transformação de ORM, não provas que ORM é necessário. Só que bibliotecas de transformação são necessárias. Há também uma limitação administrativa de se manter e atualizar tipos em ambientes de produção. O que eu geralmente faço é introduzir tipos onde se tem muita certeza da estabilidade dos requisitos de uma determinada parte do sistema, caso o ROI da introdução seja justificado. Certo. GF Pelo contrário, o SQL é mais abstrato. Ou não entendi o que quiseste dizer? Não concordo que SQL seja mais abstrato. É mais formal, porém não mais abstrato. Porém isso é difícil de medir objetivamente. Nem um pouco difícil. Bastante simples, até: em SQL, especificamos o que queremos, e podemos criar tipos abstratos de dados, isolando aplicações de muitas mudanças nos tipos e nas estruturas base, físicas e até, nalguma medida, lógicas; enquanto em OO temos de dizer como fazer, o que acaba por nos dar o problema das classes base mutantes… -- 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] Substituição dos ORM
Le 2012-9-12 17h52, Alexsander Rosa a écrit : E dava pra fazer pesquisa com grep no console mesmo... Na época eu nem conhecia grep, mas tinha um editor de textos, o ISPF/Edit ou algo assim, que matava muita coisa… tem até um clone, o THE — The Hessling Editor, mas me pareceu muito mais limitado e difícil de usar que o original. mas no geral eu via mais desvantagens do que vantagens. Como disse, cheio de limitações e ineficiências… O arquivo-texto por colunas é um extremo, um XML cheio de overhead é outro extremo, acho que o ideal é usar algo intermediário. Há intermediários e intermediários… -- 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] Substituição dos ORM
Le 2012-9-12 18h7, Eden Cardim a écrit : Essa mesma abordagem pode ser feita sem orientação a objetos, em linguagens funcionais, por exemplo, você delegaria a responsabilidade pruma função. CQD. Não há nada especificamente OO nisso. -- 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] Comparacao com Timestamp
Le 2012-7-31 9h50, Ciro a écrit : Estou tentando fazer um case, onde quero que se um valor da coluna A for igual a '0001-01-01 00:00:00' ele faca algo. O tipo da coluna eh timestamp without time zone. Código e resultado? Porem o q parece eh q ele nao entende q o valor que esta gravado no banco eh igual a esse. Rapaz, se tu não vais acentuar, pelo menos evite as abreviações. Fica ruim de ler. -- 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
[pgbr-geral] TransLattice
http://www.theregister.co.uk/2012/07/24/translattice_elastic_database_postgres/ Comentários? -- 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] Divisão de inteiros com resultado numeric
Le 2012-5-12 15h8, Anselmo Silva a écrit : conheço o cast. Mas, Como eu disse, não queria tratar a string Não entendi, por que não? É a coisa certa, tanto pela teoria, quanto pelo padrão ISO SQL. Não existe cálculo sobre seqüência de caracteres. Outros sistemas implementam, mas os detalhes são inconsistentes; com o CAST (), temos consistência. -- 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] Armazenamento de Imagens
Le 2012-3-29 0h0, alecindro a écrit : Acompanhei essa discussão, mas não vi ninguém comentar que é recomendável ter uma tabela de dados específica para as fotos. Ex.: Não colocar a foto do foto do funcionário na tabela de cadastro do funcionário. Pois ao dar uma pesquisa nos dados nessa tabela , vai carrregar fotos juntas (select * - algum descuidado) Normalmente, eu não me preocuparia com isso. Na aplicação, um erro desses vai aparecer (e ser eliminado) rapidinho. Acho até bom, para pegar algum programador mais relaxado. No uso eventual, não fará muita diferença. Acho mais grave criar necessidade de mais uma junção, de longe! -- 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] Linux
Le 2012-3-18 11h47, Luís Eduardo Porte a écrit : É possivel sim. Porem recomendaria compilar/instalar o postgresql manualmente e não pelos pacotes. Por quê? Minha recomendação é justamente o contrário para o caso geral, compilar somente se se souber exatamente o porquê para a situação específica. -- 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] Linux
Le 2012-3-17 23h5, Antonio Cesar a écrit : Pessoal estou com alguns cliente precisando usar linux como servidor. Posso usar o/Ubuntu como servidor?/ http://www.ubuntu-br.org/ Pode, mas por que não o Debian, que é a distribuição original? -- 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] Linux
Le 2012-3-18 19h18, Tiago Adami a écrit : para a versão Desktop o Ubuntu é muito mais user friendly do que sua distribuição pai (este julgamento é mais pura opinião que constatação) Não me parece ser mais verdade, principalmente depois do Unity. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ/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] Linux
Le 2012-3-18 19h24, Ruben Zevallos Jr. a écrit : não tive muita sorte usando o apt-get já com o yum foi super fácil. A longo prazo, o apt é melhor. Mas tinha de saber qual foi o problema. -- 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] Linux
Le 2012-3-18 21h5, Eduardo Alexandre a écrit : A diferença principal entre Ubuntu e Debian quanto a servidores é a versão dos pacotes. O Debian é conhecido por optar por versões de pacotes considerados estáveis e opensource. O Ubuntu não tem esses dois pontos como pilares essenciais. Basta usar o non-free para os não livres, e o testing ou o backports para as versões. -- 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] Replicação PostgreSQL 9.1
Le 2012-1-10 12h12, Eric Patrick a écrit : Alguém saberia me dizer se a replicação nativa do PostgreSQL 9.1 implementa alguma solução de balanceamento de carga? Não, porque replicação é uma função, e balanceamento outra. Seguimos a filosofia do Unix, em que cada componenete faz uma coisa, e a faz bem feita. Para balanceamento, vide pgPool, SkyTools et alli. -- 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] OFF-TOPIC - Vaga para DBA PostgreSQL
Le 2012-1-9 20h0, Victor Hugo a écrit : Tb gostaria que postar uma vaga para DBA Jr. Posso postar ? Pode e deve! -- 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] IDE gerenciamento BD para linux
Le 2012-1-4 13h38, Shander Lyrio a écrit : Em 04-01-2012 12:32, Leandro Guimarães Faria Corce DUTRA escreveu: Então colabore com o PgAdmin. É livre. Estava demorando para isto acontecer, o que tem ser livre ou não?? Ninguém falou que algo tem de ser livre, falou? O que importa é se é boa ou não, se resolve os meus problemas ou não e o PgAdmin não resolve os meus prolemas além de não ser bom o suficiente para o que eu preciso! Sai mais barato para mim pagar um valor pela ferramenta do que construir uma porque as alternativas livres não estão nem perto do caminho que eu gostaria. Ninguém sugeriu que você deixasse de pagar. Somente se disse que quem reclama duma ferramenta colabore para melhorá‐la, ou se cale. Reclamar do PgAdmin numa lista de PostgreSQL não vai ajudar nada. As opções aceitáveis são: reclamar para os desenvolvedores do PgAdmin, não na pgbr-geral; contribuir para o PgAdmin, SQuirreL ou o que quiseres, com tempo ou com dinheiro; ignorar as alternativas livres e pagar por uma proprietária. A opção inaceitável é reclamar da ferramenta livre numa lista em que as reclamações não contribuirão para sua melhoria, sem aportar nenhuma contribuição que dê o direito de reclamar de quem de fato contribuiu e do resultado dessa contribuições doutros. …eu nunca pude fazer uma doação direta para o PostgreSql, sempre faço para a SPI (Software in the Public Interest, Inc.), logo parte do meu dinheiro está sendo usada para financiar também o PgAdmin. O PgAdmin está sob a SPI? Dessa eu não sabia, é fato? Alias, porque não responde ao tópico ao invés de me agredir diretamente. Não te interessa com oque eu colaboro ou não, e me julgar antes de saber o que eu faço pela comunidade é leviano e preconceituoso. Por favor, mostre onde está a agressão e o julgamento. Quem é que está exigindo algo do PgAdmin ou do SQuirreL? Tu: O sistema de árvore que o PgAdmin utiliza é horrível… é contraproducente […] experimente utilizar o squirrelsql em um banco de dados remoto, ele sequer tem a ombridade de fazer um cache da estrutura do banco Um tom mais civilizado teria ajudado. Eu não posso exigir algo que a EMS não me vendeu Então não exija do PgAdmin ou do SQuirreL o que não venderam. Uma ferramenta ser livre não é motivo suficiente para se tornar uma boa escolha. Depende. -- 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] Dúvida sobre Roles - Papéis
Le 2011-12-30 13h56, Rubens José Rodrigues a écrit : Estou com a missão de mudar o sistema de permissões as databases Pode ser nas bases de dados? ;-) a) O search path não mostra todos os schemas setados para os grupos/roles O que seria um ‘esquema configurado’? Em portenglish ou em tradução, não me ficou claro. De qualquer maneira, se forem permissões, o caminho de busca independe das permissões, tem de ser configurado separadamente. b) O usuário/role (Rubens e Rafaela) deveriam herdar [1] todos os set´s dos grupos/roles, mas não herdou Sets? Conjuntos? Ou, novamente, seriam permissões? Deveriam herdar por quê, colocaste as palavras chave relevantes? Mostrar o que consta no catálogo para esses usuários poderia esclarecer? c) A configuração do pg_hba.conf está certa? visto que no manual é explicito quanto ao sinal (+) quando refere-se a grupo/role!? Qual o problema? Não existe mais diferença entre usuário, grupo e papel, na prática. Cenário :ambiente de testes em Windows -- produção em Solaris/Debian Deveria ser irrelevante para as questões que tentaste colocar, mas não é o ideal. -- 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
[pgbr-geral] Memoria Windows (Era: Digest pgbr-geral, volume 36, assunto 63)
Le 2011-12-30 15h34, Bruno Moreira a écrit : O windows 2003 server não suporta que um servico ultrapasse 4 gb. Isso não tem a ver com o ano ou edição do MS Windows, mas com ele ser 32 ou 64 bits, ou usar as extensões de memória, que são uma gambiarra mas funcionam. E, por favor, siga a netiqueta. Corte os trechos irrelevante da mensagem a que responde, não responda a resumos para não bagunçar o fio da meada, mantenha o assunto original, responda após o trecho citado, como neste exemplo. -- 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] Dúvida sobre Roles - Papéis
Le 2011-12-30 14h44, Rubens José Rodrigues a écrit : Sim, força do hábito misturar sintaxe, estrangeirismo com o português. Desculpe-me! Não precisa pedir desculpas — basta procurar deixar claro o que se quer dizer. Amiúde o estrangeirismo ajuda a esclarecer, mas geralmente atrapalha. Então, para o papel grupo_suporte eu configurei com o search_path para schema1,schema2,schema3,schame4,public; Neste caso, qualquer outro papel que pertencesse a este, não deveria herdar o search_path!? Não, porque caminho de busca não é permissão… Sinceramente eu não vi no manualtalvez por não ter lido atenciosamente que o search_path não é herdado e sim configurado isoladamente para cada papel. Talvez confundiste permissão com variáveis? Que eu me lembre, variáveis não se herdam… Se eu coloco o parâmetro INHERIT criacao do papel rubens, ele automaticamente deveria herdar todas as permissões configuradas de todos os outros papeis pertencentes, exceto o search_path, certo!? Hm, ao que parece realmente confundiste permissão com variável… c) A configuração do pg_hba.conf está certa? visto que no manual é explicito quanto ao sinal (+) quando refere-se a grupo/role!? Qual o problema? Não existe mais diferença entre usuário, grupo e papel, na prática. Hu, coincidência ou não, sem o sinal (+) não funciona... O pg_hba.conf continua ‘enxergando’ grupos, embora por dentro não haja diferença… mas minha questão é, ¿qual o problema? Não entendi tua pergunta. -- 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 new server
Le 2011-12-28 21h20, Daniel Montenegro a écrit : O QuantumGIS é um Sistema de Informação Geográficas que trabalha com shapefiles... Desculpa, a minha pergunta ficou ambígua. O que eu queria saber é se tu usaste o instalador da EnterpriseDB para o MS Windows. Estou usando o pgadmin no MS Windows. Ainda não conheço o DEBIAN, nem trabalho com LINUX (ainda...) Está aí uma boa oportunidade de começar. -- 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 new server
Le 2011-12-28 21h31, Daniel Montenegro a écrit : Poxa cara, aí tu me pegou... Fiz o download no próprio site do postgre, para a ver. windows. Se prestares atenção, provavelmente era o instalador da EnterpriseDB. Na verdade eu já resolvi essa questão. O campo serviço fica em branco... Sempre que resolveres uma questão que colocaste na lista, avisa… O meu foco principal agora é tentar descobrir como funciona o POSTGIS. Baixei ele no meu PC, mas não sei se está configurado adequadamente. Pois é, no Debian essas coisas são instaladas automaticamente. -- 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 new server
Le 2011-12-28 21h43, Daniel Montenegro a écrit : Que lista é essa? Aí eu já coloco a resposta! Esta! -- 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] instalar o PostGIS no PostgreSQL
Le 2011-12-28 22h13, Daniel Montenegro a écrit : como instalar (no MS Windows) o postgis no postgres - via pgadmin? O que diz o INSTALL ou o README do PostGIS? Ou o manual do mesmo? -- 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] PostgreSQL no Windowns XP (resolvido)
Le 2011-12-26 5h39, Fabiano Donato a écrit : Itamar... pois é, o Windows é mesmo uma praga maravilhosa :-) O vírus de maior sucesso do Universo. Mas como eu uso alguns programas sem versões para Linux (como um pesado programa para Poker online, que usa o PostgreSQL para estatísticas), rodá-los numa emulação a minha máquina não aguenta. Imagino não seja o caso dum BSD ou GNU/Linux para tudo o que for possível, e esses programas defeituosos isolados numa única máquina MS Windows? -- 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] erro no postgresql could not open relation
Le 2011-12-22 11h19, Pedro B. Alves a écrit : O que seria esta forma de backup PITR? Restaurar uma cópia física, tirada a quente ou a frio; e, desde o momento dessa cópia, restaurar os registros de refazer (de escrita adiantada), os WALs (Write Ahead Logs). Supondo que os registros não tenham sido perdidos — idealmente, são exportados para uma máquina separada —, podes recuperar tudo até o momento da falha. Claro que, antes de colocar o sistema em produção, tua chefia te deu tempo e recursos para criar e testar a rotina de cópia de segurança e restauração… -- 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] erro no postgresql could not open relation
Le 2011-12-22 11h39, Pedro B. Alves a écrit : Como que eu posso saber se eu tenho esta opção configurada em meu DB? Não é uma simples opção, tens de ler o manual. Basicamente, tens de ter um procedimento, bem explicado recentemente nesta mesma lista, que prepara a base para a cópia a quente, quando então tem de haver uma rotina que faça a cópia física. Como disse um colega, se não tens um DBA e não sabes do que se trata, provavelmente não tens cópia de segurança física, e estás reduzido a restaurar uma cópia lógica (/dump/), a menos que determines que todos os objetos perdidos podem ser recriados de outras fontes. Os problemas da restauração de cópia lógica são o tempo necessário, se a base for grande, e a perda dos dados alterados ou inseridos desde a última cópia. É um erro de gestão muito comum não dar tempo ao técnico de aprender e executar o básico antes de pedir melhoras funcionais. -- 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] Dúvida WAL
Le 2011-12-19 17h37, Renato Ricci a écrit :
Olá pessoal.. me tirem uma dúvida por favor... quando executo o
comando select pg_start_backup('backup') para poder sincronizar minha
pasta 'data' com o servidor slave, tema algum problema apagar os
arquivos de logs que foram gerados antes desse comando, a fim de liberar
espaço em disco?
A partir do momento que a cópia de segurança tenha sido efetuada…
Mas tenho uma sugestão melhor que confiar no que dissermos: toda rotina
de cópias de segurança deve ser testada antes de ser considerada pronta.
--
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] Cronograma de descotinuação.
Le 2011-12-14 20h26, Targino Silveira a écrit : Perfeito, valeu mesmo Euler, o postgre, foi por que estou digitando do celular e ele corrigiu para o errado. rsrsrs Pelo jeito o celular atacou de novo… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Postgres 9.1 com Lazarus no Win7 64
Le 2011-30-11 21h19, Marcelo Silva a écrit : Alguem usa essa combinação acima? Estou tentando aqui e ele me pede as DLLs, mas estão todas lá no diretorio da aplicação ‘Ele’ quem que pede? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] backup/restore
Le 2011-21-11 22h24, Marllos a écrit : Obrigado Jota. Estou usando PG 9.1.1. Pois é, ainda não entendi bem como é essa questão de tamplate 0 e template 1. Marlos, isso foi explicado recentemente. Podes procurar nos arquivos? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Chave Primaria, precisa criar indice manualmente?
Le 2011-19-11 15h27, Marcelo Silva (IG) a écrit : O PgAdmin3 não mostra indice nessa tabela E o psql? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Script está demorando muito no PostgreSQL
Le 2011-17-11 23h39, Flávio Alves Granato a écrit : Esta questão dce fsyncs já me fez largar de mongodb. Mais uma demonstração (junto com PHP, Java, Firebird, MySQL e tantos outros exemplos) de que não basta ser livre para ser bom. E, no campo dos bancos de dados, temos um indicador muito forte de qualidade: quanto mais se afasta do modelo relacional, maior a tendência à baixa qualidade. A lei de Moore esconde muita porcaria… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Script está demorando muito no PostgreSQL
Le 2011-16-11 17h19, Marllos a écrit : É o seguinte: primeiro eu crio o banco vazio, então rodo o script no PgAdminIII que: 1) cria os sequences 2) cria as tabelas 3) crias as views 4) insere os dados E quando são criados os índices? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] vários nomes numa restrição
Le 2011-14-11 12h58, Pedro Costa a écrit : A restrição que tenho é a que segue em baixo e eu queria dar um aviso diferente consoante o erro. Embora o que queres fazer seja possível, parece mais um problema de modelagem, a saber a falta dum cadastro de valores válidos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Retornar id inserido
2011/7/22 Fabiano Machado Dias fabi...@wolaksistemas.com.br: Você tem algum material, livro, documentação oficial onde isso seja documentado com mais detalhes? No caso estou me referindo as 3 repostas, lembro de já ter procurado na documentação e não ter encontrado. Não estou duvidando, apenas gostaria de ver algum artigo ou explicação mais consistente, já vi outras opiniões parecidas aqui na lista, mas nunca ninguém citou um material onde isso estivesse documentado. Não me parece que seja assunto de documentação… tem detalhes dessas informações em artigos espalhados por aí. Alguma coisa, como já disse, do David Fetter (CHAR e VARCHAR), o Josh Berkus acho que também publicou algo sobre chaves… o problema, nesse assunto, é que qualquer busca traz mil artigos de chutadores por aí. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Retornar id inserido
2011/7/21 Thiago M. Figueiredo tmarquesfiguer...@yahoo.com.br: Estou tentando dar um insert em uma tabela mais queria que já retornasse a chave primaria desde dado inserido. Supondo que a chave primária seja um serial, certo? Caso em que espero que te lembres de declarar também ao menos uma chave natural. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Retornar id inserido
2011/7/21 Thiago M. Figueiredo tmarquesfiguer...@yahoo.com.br: Sim, é uma serial. Desculpa mais não me recordo da chave natural, me recordo apenas das chaves primarias e estrangeiras. Basicamente, atributos seriais não são chaves verdadeiras, por não garantirem unicidade. Toda relação deve ter declarada ao menos uma chave natural; se não, rapidamente deixará de ser uma relação para ser apenas um saco, por falta de identificador. Um serial identifica um registro no saco, mas não uma tupla na relação. Tenho a versão 8.1 instala. Por que tão velha? -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Retornar id inserido
2011/7/21 Vinicius Santos vinicius.santos.li...@gmail.com: Usar serial como chave primária na maioria dos casos Para quê? Ou o melhor( inclusive pensando em performance ), seria simplesmente declarar: CREATE TABLE cores( descricao_cor VARCHAR(30) NOT NULL PRIMARY KEY ); ?? Claro! Aliás, nem precisa declarar NOT NULL, o PRIMARY KEY já implica nisso. Pode ser CHAR (30) mesmo, também. Considerando que a tabela tenha vários relacionamentos. Nesse caso, fica mais interessante ainda que a chave natural seja a primária, evita muitas junções provavelmente. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Retornar id inserido
2011/7/22 Vinicius Santos vinicius.santos.li...@gmail.com: Ao inserir um novo registro na tabela camisas o Postgres precisa fazer a verificação de chave estrangeira, na tabela cores. Por ser uma chave estrangeira VACHAR(30) ou CHAR(30), por exemplo, é mais caro, para o Postgres que se fossê uma chave do tipo inteira? Não. Talvez em casos muito, mas muito extremos mesmo, mas que eu saiba isso nunca foi demonstrado. Isso dito, tem um artigo interessante do David Fetter nalgum lugar recomendando evitar VARCHAR. O CHAR funciona muito bem. Será que a performance cairia, pelo fato de o tipo não ser INT ? Não. Uma junção entre chaves simples é muito mais rápido que uma entre chave composta ? Não. Ou nestes casos o que manda mesmo é sempre o bom-senso? Vou utilizar uma chave artificial pois o tipo INT é mais rápido neste caso Não é bom senso, é ato reflexo. A vantagem de não fazer junções desnecessárias, e manter a modelagem limpa, é tentadora. E conceitualmente correta. Caso estas questões de tipo sejam apenas lendas urbanas não vejo motivo algum para chaves artificiais. Estou errado ? Há muitas ferramentas que forçam o programador a escrever cada parte de uma chave composta, por não terem operadores sobre um conjunto de variáveis. Não tem nada a ver com modernidade, o Cobol já fazia isso direito há quarenta anos, pelo menos. Isso leva os programadores a procurarem criar uma chave simples. O problema é se criam chave artificial mesmo quando as naturais serviriam perfeitamente, e pior ainda quando esquecem de declarar as chaves naturais ao lado da artificial. Outra situação que pode exigir uma chave artificial é quando (1) as chaves naturais de uma relação (tabela) são todas compostas de muitos atributos, e (2) exportadas para várias relações filhas maiores que a pai, e (3) isso num volume muito, muito alto. Aí poderia, eventualmente, acontecer da diferença de volume de dados armazenado e em memória ser significativa. Deve haver alguma outra exceção à regra de evitar chaves artificiais que não me lembro. O que não há é exceção à regra de sempre declarar pelo menos uma chave natural, mesmo que se tenha sido obrigado a criar uma artificial. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Retornar id inserido
2011/7/22 Bruno Silva bemanuel...@gmail.com: Pessoal, a discussao esta muito boa mas fugimos do tópico. Verdade — nesses casos, é bom mudar a linha de assunto. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Retornar id inserido
2011/7/22 Bruno Silva bemanuel...@gmail.com: Oba Vinicius, nao estou querendo quebrar o conversa, só mudarmos o Assunto pra nao fica confuso em futuras pesquisas. Pois é, eu dei a dica do que fazer — e não fiz… :-( -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Novato com uma dúvida, campo PK sendo GUID
2011/7/13 Alexsander Rosa alexsander.r...@gmail.com: 1) CPF compartilhado por marido e esposa. O marido é um cliente, a esposa é outro cliente. Se a chave primária simples for o CPF, um deles não poderá se cadastrar. Neste caso é melhor usar uma chave artificial como código do cliente. De novo confusão. Se código do cliente for requisito de negócio, não será artificial; e, de qualquer maneira, o uso de um código não garante unicidade, continua sendo necessário declarar pelo menos uma chave natural. O mesmo vale para seu item (2) 3) Se o código do cliente for inaceitável para as regras de negócio, uma possível maneira de manter o purismo e contonar a imperfeição do mundo real seria fazer a chave primária ser composta -- por exemplo, CPF/CNPJ + número sequencial. No mundo real das aplicações comerciais, no entanto, a regra é trabalhar com código de cliente -- esta chave composta raramente seria necessária. Conceitualmente não importa qual seria a chave primária, desde que haja ao menos uma chave declarada que garanta a unicidade. Isso porque conceitualmente não faz a menor diferença qual das chaves é a primária. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Novato com uma dúvida, campo PK sendo GUID
2011/7/13 Alexsander Rosa alexsander.r...@gmail.com: Assim fica difícil manter o debate, você argumenta contra seus próprios espantalhos... :-) Minha impressão é que ainda não entendeste nada… Encerrei por aqui, siga usando CPF e CNPJ como chave primária simples se quiser. Exatamente o que disse que não precisa nem pode. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Encode da Base Latin1 postgresql 9.0.4
2011/7/13 Emerson Martins emersonmarti...@gmail.com: Fiz uma instalação anteriormente..em 8.4 consegui criar um banco de dados com com encode em latin1; Não dá para atualizar para alguma codificação que não esteja obsoleta? Latin1 está obsoleto, não tem nem o € nem o œ. O ideal seria UTF‐8, pelo menos o Latin9. postgres@Debian01:~$ /usr/local/pgsql/bin/createdb --encoding=LATIN1 /usr/local/pgsql/data/ createdb: database creation failed: ERROR: encoding LATIN1 does not match locale pt_BR.UTF-8 DETAIL: The chosen LC_CTYPE setting requires encoding UTF8. O histórico da lista já respondeu isso algumas vezes, creio? -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Novato com uma dúvida, campo PK sendo GUID
2011/7/12 Alexsander Rosa alexsander.r...@gmail.com: Comentários no texto: Ufa, obrigado. Em 11 de julho de 2011 17:50, Leandro DUTRA leandro.gfc.du...@gmail.com escreveu: Péssimo exemplo, visto que essa definitivamente não é uma chave natural válida. O exemplo CPF + NOME como chave natural foi sugerido aqui mesmo neste tópico, algumas mensagens atrás: portanto, as chave naturais incluirão algo mais, como endereço, nome… Também acho estranho. [1] Da minha sugestão genérica para esse exemplo específico há uma distância enorme. Se não me engano, algo mais são poderia ser CNPJ mais nome, supondo que não haja duas escolas gaúchas com o mesmo nome… Chaves primárias como código de cliente e número de pedido, compostas ou não, são quase inevitáveis. Quase, mas nem sempre. E muitas vezes por limitações tecnológicas arbitrárias, não motivos conceituais válidos. Na minha opinião, não se trata de limitação tecnológica, mas de regra de negócio. Como disse, antes, se é regra de negócio já não são chaves artificiais, então não há problema. A questão de se são chaves primárias ou não é conceitualmente irrelevante, mas tem-se absolutamente de lembrar que, como esses códigos não garantem unicidade, no caso de existirem tem de haver pelo menos uma outra chave. Se é uma definição de negócio, deixa de ser uma chave artificial e passa a ser natural. Aí a única questão passa a ser definir uma chave natural alternativa. Exatamente! Código de cliente e número de pedido nascem como artificiais Não se são decorrentes de regras de negócio. se tornam, ao adentrar o mundo real, chaves naturais. E mais: estas são chaves naturais que podem, também, ser chaves primárias. CPF e CNPJ, por outro lado, podem ser chaves naturais (compostas, se necessário), mas não são boas chaves primárias pelos motivos expostos anteriormente. Motivos esses todos inválidos. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Novato com uma dúvida, campo PK sendo GUID
2011/7/11 Alexsander Rosa alexsander.r...@gmail.com: …nem CPF nem CNPJ servem como PK: o CPF é reusado alguns anos depois do falecimento do titular Portanto, a chave natural inclui uma dimensão temporal. E bases de dados temporais são um problema, digamos, interessante. e muitos órgãos ṕublicos compartilham o mesmo CNPJ -- por exemplo, TODAS as escolas estaduais do RS usam o CNPJ da Secretaria da Educação do estado. Portanto, as chave naturais incluirão algo mais, como endereço, nome… -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Novato com uma dúvida, campo PK sendo GUID
2011/7/11 Alexsander Rosa alexsander.r...@gmail.com: Sim, mas o OP estava falando sobre PK; o meu argumento é que CPF e CNPJ não servem como PK há duplicidade nos dois: esposas com CPF de maridos, escolas estaduais com CNPJ da Secretaria de Educação, etc. Com algo mais (nome, etc) são excelentes chaves naturais -- mas não PK. Me parece que está havendo uma grande confusão entre chave simples e chave primária. A chave primária *não precisa* ser simples, pode ser _composta_! -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Novato com uma dúvida, campo PK sendo GUID
2011/7/11 Alexsander Rosa alexsander.r...@gmail.com: Sim, obviamente, mas quem usaria CPF + NOME como chave primária de CLIENTE (ou PESSOA)? Péssimo exemplo, visto que essa definitivamente não é uma chave natural válida. Chaves primárias como código de cliente e número de pedido, compostas ou não, são quase inevitáveis. Quase, mas nem sempre. E muitas vezes por limitações tecnológicas arbitrárias, não motivos conceituais válidos. As pessoas estão acostumadas a receber um número de pedido quando compram alguma coisa. Se é uma definição de negócio, deixa de ser uma chave artificial e passa a ser natural. Aí a única questão passa a ser definir uma chave natural alternativa. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Capacidade de gerenciamento do Postgre
2011/7/11 Rodrigo Dias Ribeiro da Silva rodrigo.d...@gmail.com: É melhor usar SK ( ou Chave Sintetica ) por que o Lat-Long não é unico já que existe várias datas como o mesmo; Ou seja, a chave poderia ser (lat-long, data). Talvez uma Chave Sintética seja interessante ou ainda uma indexação com a coluna Lat-Long e as Datas ... Não confundir chaves (identificação) com índices (desempenho). -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Capacidade de gerenciamento do Postgre
2011/7/11 George Rodrigues da Cunha Silva georger.si...@gmail.com: Leandro, no paradigma do geoprocessamento, as chaves sintéticas são importantes sim. Creio que há uma grande confusão aí, que como só acontecer em bases de dados é a mesma velha confusão entre os níveis lógico e físico. Um pretenso ‘paradigma’ nada tem a falar sobre chaves sintéticas, por serem do nível físico. Paradigmas são, por definição, conceituais. Esse é um problema de ferramental, apenas. Ferramentas open-source e proprietárias trabalham da mesma maneira. O que nada prova… um erro cometido por duas pessoas ou grupos não deixa de ser um erro, não é mais correto que um cometido por um só grupo. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Novato com uma dúvida, campo PK sendo GUID
Por favor, vamos seguir a netiqueta, RFC 1855… cortar os trechos da mensagem a que não se respondeu, e colocar a resposta após o texto relevante. 2011/7/11 Aldemir Vieira alde...@gmail.com: Peraí A técnica/teoria implementa as duas. As duas são feitas para serem usadas. Use-as, inclusive no mesmo projeto, pois a adoção de uma não exclui a adoção da outra. Ambas podem conviver em total harmonia. Mas a tecnologia (nível físico) tem muitas restrições arbitrárias, perdendo muito do poder e da elegância da teoria. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 MSNIM:chat?contact=lean...@dutra.fastmail.fm sip:leand...@iptel.org ICQ: AIM:GoIM?screenname=61287803 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Vantagens de se usar Domains
2011/7/6 Fellipe Henrique felli...@gmail.com: …se eu criar um Domain.. por exemplo Char(50).. usar ele em algumas tabelas, e depois quiser mudar ele pra Char(100) o Postgre não deixa.. isso é verdade? Não que eu me lembre. URI para o manual onde diz isso? -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Amigos sou novato em banco de dados
2011/7/6 * Pro1000 Tecnologia e Projetos * pro1...@pro1000.com.br: Olá , eu sou novato em banco de dados e preciso aprender postgres Eu diria que, antes de aprender PostgreSQL, precisa aprender dados: DATE, Chris(topher) J, _An Introduction to Database Systems_, 8th. edition. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Novato com uma dúvida, campo PK sendo GUID
2011/7/6 Fellipe Henrique felli...@gmail.com: Sim, a idéia é usar Chave Composta, mas usando integer seria complicado quando fosse fazer a importação, pra ter que refazer os conflitos das FK... Teu problema é de modelagem. Usar chaves naturais evitaria todo esse problema. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Vantagens de se usar Domains
2011/7/6 Fellipe Henrique felli...@gmail.com: o ideal é usar o normal memso, já que ele me permite mudar caso eu queira o tamanho do campo... Não, use o DOMAIN e crie um novo quando precisar. Dá mais trabalho, mas o modelo fica mais limpo. Precisa ver se essa capacidade já está nos planos. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Vantagens de se usar Domains
2011/7/6 Fellipe Henrique felli...@gmail.com: Entendi.. é que na minha cabeça, a maior vantagem do Domain seria quando eu quisesse mudar o tamanho, aí mudaria em todas as tabelas que usam ele.. E pode, só dá mais trabalho que no Firebird. já aconteceu comigo de ter que aumentar um campo Char(8) pra Char(15). e foi em quase 200 tabelas... mas eu conseguindo criar uma Function, mudando de um Domain para outro Domain novo, já alivia minha mente... Nem precisa função, acho mais simples fazer consultas no catálogo para gerar programetas. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Novato com uma dúvida, campo PK sendo GUID
2011/7/6 Fellipe Henrique felli...@gmail.com: Hum.. acredito que o problema esteja além da modelagem. Não, é exatamente modelagem. Todo o problema que delineias é decorrente do uso de chaves artificiais. Chaves naturais resolveriam o problema. Há outras soluções, chaves naturais são a mais genérica. A mais específica seria separar faixas para cada modelo fonte. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Novato com uma dúvida, campo PK sendo GUID
2011/7/6 Fellipe Henrique felli...@gmail.com: Rapaz.. to meio lento ainda.. pensei, pensei, mas não consegui achar uma forma de usar Chaves Naturais eliminar esse problema... voce poderia dar um pequeno exemplo? Desculpa, não posso parar para fazer isso. Mas sugiro leitura básica sobre chaves naturais, talvez o Date… -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] [PVT] Chaves Naturais
Procure manter todas as discussões técnicas na lista, por favor. 2011/7/6 Tiago Adami adam...@gmail.com: Veja que não há um campo artificial para código. O fato é que, obviamente, a chave desta tabela seria o atributo NAME. Mas pelo o que entendi dos requisitos, o nome da categoria poderá ser alterado, então vejo aí uma FK com ON UPDATE CASCADE para alterar o valor nas tabelas filhas. Entretanto, estima-se que as tabelas filhas terão mais de 100.000 registros por categoria, e na eventualidade de uma alteração de nome de categoria a operação seria extremamente demorada dadas as estimativas iniciais de registros nas tabelas filhas, que poderão ter até 200 milhões de registros. Baseado em sua experiência, o que você me diria sobre este caso? O uso de uma chave artificial seria justificada? Possivelmente, mas eu consideraria otimização precoce. Cem mil registros em 200 milhões não parece ser tão problemático assim, para um sistema que ainda nem foi montado. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Vantagens de se usar Domains
2011/7/6 Fabrízio de Royes Mello fabriziome...@gmail.com: [1] http://wiki.postgresql.org/wiki/Todo#ALTER Muito bom! Pena que não está marcado como fácil, nem como feito para a 9.1… -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Versões do PostgreSQL
2011/7/5 Rodrigo Della Justina rodrigodellajust...@gmail.com: A versão 9.x.xxx do PostgreSQL é confiável ? Sim. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Versões do PostgreSQL
2011/7/5 Evandro Andersen evandro.ander...@gmail.com: Apesar da grande rejeição do Windows por parte da comunidade do Postgresql, no meu caso ele tem se mostrado muito estável, Ele quem, o MS Windows ou o PostgreSQL? -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Versões do PostgreSQL
2011/7/5 Evandro Andersen evandro.ander...@gmail.com: Ambos Então, seriam ‘eles’. E aí repito o que já disse quando morei em Londrina, dez anos atrás: o MS Windows é estável para quem nunca experimentou nada melhor. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Versões do PostgreSQL
2011/7/5 Bruno Silva bemanuel...@gmail.com: O pessoal confunde instabilidade achando que é o fato de ter de reiniciar a máquina. E ter de reiniciar não é por instabilidade? Ou reiniciar, digamos, mensalmente, é uma instabilidade estável? -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Versões do PostgreSQL
2011/7/5 George Rodrigues da Cunha Silva georger.si...@gmail.com: Pela minha experiência (versões 8.2) o PostgreSQL sempre foi estável em Windows. Na medida em que o SO permite, claro. Não podemos esquecer, que existem clientes que já possuem um determinado setup, impossibilitando o uso de servers em outros SOs. Neste caso, não há muito o que fazer. A existência é um dado, mas não o único. O ideal é poder fazer um plano de migração para sistemas livres. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Versões do PostgreSQL
2011/7/5 Evandro Andersen evandro.ander...@gmail.com: pro cliente não importa se o Sistema é Windows, Linux, Mac, se é 32 ou 64b, o cliente quer o sistema funcionando de forma estável, rápida e segura, e Segurança e estabilidade em MS Windows? Só creio vendo. a questão não é ser melhor ou pior Para quem gosta do que faz, isso é, sim, uma questão. e sim se funciona bem ou não O que é relativo a, entre outras coisas, as alternativas e as expectativas. hoje o Postgresql funciona muito bem no Windows. Claro, na medida do possível. ps: Windows é igual a FIAT, ficou marcada pelo Fiat 147, tem gente que até hoje não compra FIAT por causa do 147. A comparação é injusta com a Fiat. Os Fiat hoje são tão bons quanto outros carros europeus de mesmo preço, enquanto a Microsoft continua proprietária, insegura e instável. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] instalação do Postgresql 9.0.4 no Debian 6
2011/7/5 Emerson Martins emersonmarti...@gmail.com: Pessoal estou tentando instalar o postgresql 9.0.4 pelos fontes no Debian 6, Não achaste os pacotes? -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Versões do PostgreSQL
2011/7/5 Bruno Silva bemanuel...@gmail.com: A implementação do NTFS pesa na performance do Postgres. Acho que era essa a dúvida inicial né? A dúvida inicial era se o PostgreSQL 9 é confiável… o que, obviamente, também será limitado pelo SO. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Versões do PostgreSQL
2011/7/5 Vinicius Santos vinicius.santos.li...@gmail.com: Mas você não pode dizer que um software privativo é sempre pior técnicamente que um livre. Não. Mas, ceteris paribus, geralmente é. As empresas ainda sofrem na mão da SAP, pois não existem ERP livres tão bons técnicamente. Será? Existem vários ERPs livres sim, mas tenha certeza que não atendem à uma variedade de companhias. Isso é qualidade técnica? Ou, simplesmente, maturidade de mercado? Você pode dizer que Linux é melhor que Windows, claro, mas não é por causa do modelo de desenvolvimento. No máximo o modelo piora as coisas. Não somente por causa, mas principalmente. Eu utilizo BrOffice, e me atende 100%, mas o MS Word tem mais recursos, é mais completo, portanto técnicamente é melhor. Não é verdade. Por exemplo, o LibreOffice tem estilos mais completos, contemplando elementos como páginas e módulos como o Impress, coisas que o MS Office não tem. Sem contar que roda em qualquer plataforma, e gera ODTs, que o Office não faz ou faz mal. Agora, se o assunto for qualidade, e não apenas cobertura, não tem disputa. O LibreOffice dá muito menos pau que o MS Office, por exemplo com documentos complexos ou muito grandes. Um escritor muito exigente pode precisar de recursos apenas encontrado no MS Word. Estou para ver quais. Não estou defendendo ninguém, apenas acho errado dizer que um software é ruim porque tem o código fechado, sem olhar mais a fundo. As exceções geralmente estão no campo científico (Mathematica, por exemplo) ou de /mainframes/ (DB2, p. ex.). De maneira geral, é verdade. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Versões do PostgreSQL
2011/7/6 Alexsandro Haag alexsandro.h...@gmail.com: Mas aih voltamos na mesma... Com oracle usem Linux. Recomendaçao da mesma. A Oracle inclusive tem um kernel otimizado para seu banco de dados para sua distro. Diz a lenda que, mesmo assim, o Oracle ainda rodava melhor no Debian. Né, FIke? -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Livro de SQL com ênfase em recursividade
2011/7/4 Fábio Telles Rodriguez fabio.tel...@gmail.com: Senhores, estou precisando dar uma aprofundada nos meus estudos de CTE com recursividade, pensei em comprar algum livro do Joe Celko. Vi que ele tem vários. Sim, mas o Celko é muito ruim. Não apenas conceitualmente, com a confusão sobre o modelo relacional, mas na prática, com seu idiótico ‘modelo de conjuntos aninhados‘. Alguém me recomenda algum bom livro sobre o assunto? Na verdade, gostaria de entender melhor a necessidade… afinal, temos a documentação do PostgreSQL, o código-fonte do mesmo, e os muitos artigos escritos por aí a respeito… o que falta? Algo mais didático para emprestar a usuários programadores? -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Criar usuário apenas para relatórios
2011/7/4 Flavio Henrique Araque Gurgel fha...@gmail.com: Preciso criar um usuário apenas para emissão de relatórios, CREATE USER xpto PASSWORD 'qwerty'; Ou, melhor ainda, criar um papel (ROLE) e concedê‐lo aos usuários interessados. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Problema com campo TIMESTAMP e driver JDBC
2011/7/1 Juliano Benvenuto Piovezan juli...@sinersoft.com.br: Esse é um bug conhecido, que ainda não foi corrigido, vide [1]. Teste retirando a opção de ajustar o relógio automaticamente no horário de verão e verá que o problema sumirá. [1] http://bugs.sun.com/view_bug.do?bug_id=4677493 Dois dos meus horrores prediletos interagindo: Java e MS Windows. Claro, tempo (horário c) na MS é horroroso! Algum Java livre que evite o problema? -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Problema com campo TIMESTAMP e driver JDBC
2011/7/1 Bruno Silva bemanuel...@gmail.com: Não entendo esse medo de Java que as pessoas têm. Excesso de complexidade. ¿Já ouviste falar que o cavalo definido por comitê é um camelo? Justiça seja feita, o mesmo se aplica ao C++ (comparando ao Objective C, por exemplo), aos sistemas Posix (comparando com o Plan 9, por exemplo), ao SQL (comparado ao modelo relacional) c. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Problema com campo TIMESTAMP e driver JDBC
2011/7/1 Bruno Silva bemanuel...@gmail.com: Não é assim também. Não é esse o tópico mas, vejo sempre que pelo fato de se ter muita coisa que pode ser utilizada em Java, os programadores as vezes cometem o pecado de querer colocar tudo, aí fica complexo mesmo. Acho que não entendeste — orientação a objetos em si já é complexo; como ela é feita em C++ é mais ainda; como o Java importou os conceitos do C++, mais ainda; as implementações do Java, ainda mais; e o Java sobre o MS Windows, então… Como dizia um chefe meu, a solução para todos os problemas na Informática são camadas sobre camadas. Na teoria, muito bonito, na prática é um terror. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] RES: RES: Problema com campo TIMESTAMP e driver JDBC
2011/7/1 Charles Viana charles.vi...@gmail.com: Isso acontece tanto no linux,BSD e windows onde ajustar automaticamente o relogio para horario de verão estiver marcado. Essa ‘marcação’ só existe no MS Windows, não? Os outros sistemas usam UTC. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] RES: RES: Problema com campo TIMESTAMP e driver JDBC
2011/7/1 Charles Viana charles.vi...@gmail.com: Se vc estiver com KDE ou Gnome vc vai ver ela. Não estou… StumpWM. Tenho servidor de email com instalação minima e esse erro ocorre se deixar o zic configurado. Bom, isso não é uma marcação. E, aliás, revendo as tuas referências anteriores, o problema é JavaScript não conhecer hora direito, não a configuração correta do sistema operacional. Ou entendi errado, talvez? Não estou muito legal hoje. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Postgres X PHP x Caracteres especiais
2011/6/30 Marcelo Silva (IG) marc...@ig.com.br: $Conexao-charSet = LATIN1; // Tentei adicionar esta linha mas nada Latin 1 está obsoleto. Os conjuntos atualizados são o Latin 9 (ISO/IEC 8859-15:1999) e o UTF‐8 (UCS Transformation Format — 8-bit), entre outros. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Postgres X PHP x Caracteres especiais
2011/6/30 Flavio Henrique Araque Gurgel fha...@gmail.com: Não use o usuário postgres para aplicações. Crie um usuário restrito para isso. Troque esse usuário pelo usuario_sua_app_php acima. Você pode criar diretamente assim: CREATE USER usuario_sua_app_php PASSWORD 'senha' SET client_encoding='LATIN1'; Ou, melhor ainda, passe as credenciais do usuário. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Problema com campo TIMESTAMP e driver JDBC
2011/6/30 Marques alexandremarquesalme...@gmail.com: Estou com um problema quando acesso dados do tipo TIMESTAMP via driver JDBC. O Ministério da Sanidade adverte: Java faz mal à saúde mental emocional. Falando sério, fiquei curioso, também. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Sugestão de uso
2011/6/29 Flavio Henrique Araque Gurgel fha...@gmail.com: Meus dois centavos nesta discussão vão na direção contrária. Vou discordar, correndo o risco de parecer ridículo — afinal, tu representas *o* caso de PostgreSQL do milênio… - A idéia é péssima no sentido contrário: a aplicação tem centenas de milhares de usuários e funciona em escala nacional. Como toda a regra de negócio está no banco, o consumo de CPU é altíssimo, batendo em 100% em máquinas bastante parrudas. Claro que não tenho como questionar, não tenho informações suficientes nem, no momento, quero ter… mas essa é uma questão interessante. Regras de negócio causando uso total de processadores no servidor de bases de dados, na minha experiência e na lógica que chego a alcançar, costuma indicar problemas de codificação, principalmente por uso de modelos de programação descasados com o modelo relacional, como o navigacional e o POG: respectivamente, tipicamente representados pelos clipeiros e pelo Hibernate, claro que nem de longe exclusiva, embora talvez majoritariamente. A outra grande causa de uso exagerado de recursos computacionais pelas regras de negócio costuma ser má modelagem, de novo por falta de entendimento do modelo relacional. Por exemplo, a famigerada ‘desnormalização’, o uso indiscriminado de chaves artificiais, a falta de uso dos tipos definidos por usuário (tipos ‘abstratos’ de dados) c. Claro que, muitas vezes, o pobre do DBA, que deveria receber adicional de insalubridade por ser, na prática, gari de curva de rio, não tem como garantir nem o modelo, nem a qualidade da programação. Mas creio que vale a pena mencionar para que não fique parecendo que a ‘culpa’ é da garantia das regras de negócio no SGBD. Isso deveria ser um requisito conceitual absoluto, embora nem sempre o SQL facilite e quase nunca a organização tenha competência (ou as famosas ‘condições objetivas’) para alcançar. Quando é necessário aumentar a escala de atendimento, é necessário colocar máquina mais poderosa. Hm, quando armazenamento de massa em memória /flash/ se tornar mais lugar comum, conquistar nossa confiança, for bem aproveitada por nossos sistemas de arquivos… quem sabe consigamos implementar os conceitos do saudoso (em parte) /mainframe/, como as hierarquias de memórias e armazenamento. Isso depois de muito tuning e uso de PostgreSQL 9 onde a parte de BI e relatórios com consultas mais complicadas são feitas em servidor hot-standby. Até aí, seguindo as regras, né? Morreu o Neves, quem faz diferente é quem tem de se explicar… Para escalar horizontalmente esse ambiente, só há uma forma: modificar toda a estrutura do banco quando estiver disponível totalmente a implementação de SQL-MED, pra poder fazer com mais facilidade o uso de dados remotos e separar fisicamente tabelas por regiões ou estados. Experiência com Oracle em telecom (operadoras de telefonia fixa celular): mesmo uma implementação meia‐boca e mal compreendida, como é a da Oracle, pode trazer grandes ganhos. No caso, tínhamos as tabelas ditas ‘de referência’ em pequenos servidores localizados juntos a setores administrativos, de atendimento ao usuário c, que salvavam a pele dos programas aplicativos cliente‐servidor. Está certo que eu, particularmente, não ‘acredito’ nem em cliente‐servidor nem em nenhum papai‐noel da vida, mas às vezes tem‐se de fazer malabarismo para impedir que o estrume alcance o proverbial ventilador… Se a regra de negócio estivesse na camada de aplicação, seria possível dividir dados usando alguma técnica de sharding com mais facilidade e menos alterações em código. Sim, com a tecnologia atual, sim. Pelo pouco que entendo do SQL‐MED, nem ele chega a implementar de verdade um SGBDDistribuídas. Idealmente, poderíamos programar, digamos, em SQL/PSM ou PL/Scheme ou o que bem entendêssemos, e deslocar o código transparentemente entre servidores. Mesmo assim, a minha expectativa seria de que, freqüentemente, descobriríamos que as regras de negócio teriam melhor desempenho junto da base, por evitarem latências decorrentes de mudanças de contexto, transferências de dados pela rede c. Minha dica para novos sistemas é sempre assim: - regra de negócio sempre numa camada fora do banco de dados; - llinguagens procedurais devem e podem ser utilizadas, mas de forma restrita para as funcionalidades de banco de dados (ex.: particionamento, regras para suprir restrições, validação de dados não possíveis por restrições, etc); Pois é, mas se considerarmos que todas as regras de negócios devem ser implementadas como restrições, de preferência declarativas, fica contraditório ter isso fora da base, não? Ou minha lógica falhou nalgum ponto que não alcancei? Sim, claro, o SQL não é relacional, isso impõe restrições e tudo o mais… mas o PostgreSQL, particularmente, é suficientemente próximo do ISO SQL:2008, e até do modelo relacional, para o desenvolvimento de um novo sistema aplicativo por uma equipe
Re: [pgbr-geral] Avaliando a ordem de colunas em índices compostos
2011/6/28 Dickson S. Guedes lis...@guedesoft.net: Você está falando da fadinha [1] Dutra? Parece que ela(e) morreu mesmo. SQL Alchemy, na verdade. O SQL Fairy (sql::fairy para os íntimos) não morreu, que eu saiba, embora precise dum trato, sem dúvida — de qualquer maneira, o Fairy, creio, nada tem a ver com mapeamento objeto‐SQL (continuo objetando fortemente ao nome ORM). Me lembro duma ou outra tentativa de jogar para outros ambientes os conceitos do SQL Alchemy, mas não lembro quais eram nem no que deram. Acho que o grande senhor doutor Diogo Biazus me falara que o Ruby on Rails teria um mapeamento mais são na versão três, não lembro se tão bom quanto o SQL Alchemy. Em tempo, tive bons contatos com ActiveRecord do Rails [2] Acho que és o primeiro DBA são que conheço que diz isso! :-) as técnicas que vi no mesmo mostram um amadurecimento cada vez maior e um uso mais efetivo do mesmo junto com o banco de dados. Bom, era tão ruim que só podia melhorar mesmo… piorar era praticamente impossível, embora num mundo que tem o Hibernate fica difícil imaginar o que seria o fundo do poço… não, me recuso a lembrar do Clipper… Eagers e Lazys Joins quando bem utilizados realmente mudam consideravelmente a performance. É, preciso voltar a ler e estudar. Boiei, confesso. Claro que existem certas convenções do AR que não são tão bem vistas, como as SKs [3] por exemplo, mas para determinadas aplicações isso não é o fim do mundo em si. Cara, é o fim do mundo. É a base opaca, não escalável, engessada. Mas isso já discutimos tanto, aqui e alhures… deixa quieto. A questão em si é que quando mais você entende as ferramentas que usa, melhor proveito você pode tirar delas. E, IMHO, o marketing feito sobre certas 'facilidades' dos ORMs é que leva a muitos desenvolvedores acharem que podem esquecer de tudo pois o ORM cuidará disso pra você. Minha pergunta é só quando podemos declarar o início da IdT II (segunda Idade das Trevas), e quanto tempo durará… minha esperança é que comece ainda daqui a algumas gerações, e demore menos que o milênio que a IdT I durou. Ou que a Segunda Vinda seja antes. [1] http://sqlfairy.sourceforge.net/ [2] http://guides.rubyonrails.org/active_record_querying.html [3] http://en.wikipedia.org/wiki/Surrogate_key -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Erro pg_class_oid_index
2011/6/29 emerson lopes emerson.pal...@gmail.com: Obrigado pelo apoio. Problema resolvido ! Killer elephants! -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Sugestão de uso
2011/6/29 Fabiano Machado Dias fabi...@wolaksistemas.com.br: Conseguimos isso e muito mais, a modelagem mudou radicalmente, usamos a tão falada chave artificial para as PKs e fizemos as restrições devidas nas chaves naturais (UKs), assim conseguimos resolver os problemas do modelo físico e do lógico, claro que eles se misturam (não chegam ao usuário mas ao programador sim), mas pra nós não é problema, aliás nunca foi. (Por favor, não quero criar polêmica de novo rsrsrs, é só a minha resposta a pergunta do colega!) Depois de trabalhar com tabelas em que a PK era composta por 16 campos e tinha que juntar mais mais outras 20 tabelas, abolimos as PKs compostas, isso me deu um ganho de performance bom e uma escrita rápida também, a criação de índices também ficou fácil. Esse é o plano B, melhor que as outras alternativas. O plano A, claro, seria usar chaves artificiais somente onde necessário, tipicamente mantendo as chaves compostas, onde não implicassem em perda de desempenho, como primárias. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Sugestão de uso
2011/6/29 Flavio Henrique Araque Gurgel fha...@gmail.com: Esta thread está ficando agradavelmente construtiva! Ufa! Já estava com medo do Teles pedir para eu baixar a bola… E olha que, neste caso, nem estou falando d*o* case do milênio :) Nele o banco de dados é praticamente um saco de dados. E pensar que tem dinheiro público nisso… privatização já! Se querem desperdiçar dinheiro, que seja privado… mas, enfim, o setor privado às vezes me parece estar ainda mais atrasado que o público, no quesito liberdade de Informática… pelo menos, no caso de empresas estabelecidas ou que não são de Informática. E o SGBD: Cata os dados, valida input, trata strings, verifica consistência em todas as tabelas relacionadas, insere cada pedaço do formulário em 10 tabelas diferentes, atualiza a tabela de histórico, computa sequências, atualiza índices, checa as restrições locais e estrangeiras e comita tudo. Não parece coisa de clipeiro? Digo, fazendo proceduralmente o que poderia ser declarativo? Ou entendi errado? Agora no duro: se a parte toda de validação de input e tratamento de strings fosse na aplicação, a aplicação abrisse uma transação com o banco e resolvesse sua vida, o processamento de cada passo no pl/pgsql poderia muito bem ser dela, distribuindo bem melhor a carga entre seus três servidores. Mas validação não costuma ser conformidade a tipos de dados e integridade referencial, pelo menos num sistema bem modelado? Nesse caso, se entendi direito, o que chamas de validação não tem de ser, em última instância, garantido pelo SGBD? Talvez tenhamos, aí, outra limitação tecnológica. O único sistema de desenvolvimento e execução de programas aplicativos realmente integrado ao SGBD e ao modelo relacional que conheço é o Alphora Dataphor — que, acho, infelizmente inda não foi portado nem para Mono, nem sequer para PostgreSQL —, e ele resolve essa questão exportando, automaticamente, as restrições de integridade da base para a interface, mesmo que cliente servidor; no caso, o cliente interpreta (ou compila, sei lá) o mesmo código D (D4) que a base, e é atualizado automaticamente quando a base muda. Vamos então nomear melhor os bois: a regra tem que estar no SGBD sim, ok. Restrições, regras e etc. Mas o processamento das informações _antes_ de chegar no SGBD, isso não deveria estar com ele. E, neste caso, está. Perfeito. O agora Microsoft Skype tem um excelente caso de sucesso justamente separando tudo: chamada remota de função com o plproxy é um sucesso. Sim, mas é um caso bem específico, de quase perversão da base para escalabilidade extrema. E, juro, mandei estudo disso para o cliente. Era só modificar 70 funções em pl/pgsql e a aplicação toda, mas ia ficar da hora. O custo foi proibitivo e ameaçaram trocar pelo RAC se fossem gastar a grana toda :P De fato, uma das vantagens teóricas do modelo relacional que perdemos por causa das limitações do SQL, entre outros fatores, é não precisar alterar a aplicação por mudança no modelo físico… Pois é, mas se considerarmos que todas as regras de negócios devem ser implementadas como restrições, de preferência declarativas, fica contraditório ter isso fora da base, não? Ou minha lógica falhou nalgum ponto que não alcancei? Como falei acima, tô contigo na questão regra de negócio. O problema é o processamento do negócio. IMHO, deve estar fora do SGBD. Pode me esclarecer o que consideras ‘processamento do negócio’ em contraposição a ‘regra de negócio’? Talvez eu não tenha entendido direito. PostgreSQL é a melhor implementação da ISO, reconhecido e utilizado academicamente por isso. Concordo, só não lembro se já passamos a conformidade do DB2 — que obviamente não serve para a Academia. E olha que a comunidade não tem dinheiro pra ficar comprando norma. :-) Aliás, norma, do jeito como é no nosso mundo, na minha opinião, é só um jeito de ganhar dinheiro com patent war. Concordo — gênero, número grau. E caso. Não contigo, com a gramática. Existem sim. Os integrantes dessas equipes se chamam nerds. E eles estão em alta no mercado de trabalho e até na vida afetiva. Não posso reclamar no afetivo, mas no mercado de trabalho acho que não fui /nerd/ suficiente, virei burocrata. Claro que tem que ter um balanço: nerdice versus praticidade. Não acho que o mundo deva ser 100% nerd pra fazer as coisas em TI. Ninguém ganharia dinheiro. Eu proponho um balanço: bem feito na medida, tem que ser bem feito mas tem que ser prático ou não vai pra frente. Creio que, se todos fizessem bem feito, haveria inda mais dinheiro, que a demanda reprimida nunca cessa de crescer. Vou te contar algo que vai te deixar bem chateado. A maioria das aplicações Java EE usando Hibernate, normalmente, são independentes de SGBD. Tendo o driver JDBC correto, elas falam o dialeto adequado. Eu sei, mas a que custo? Esse é o ponto. É sempre o uso dum mínimo denominador comum, por exemplo excluindo absolutamente o uso de
Re: [pgbr-geral] Postgres e Servdor com 6 CPUS Quad - Melhor uso
2011/6/29 Bruno Silva bemanuel...@gmail.com: Já o fiz. Mudei o mínimo para um número maior. ¿E o resultado foi…? -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Avaliando a ordem de colunas em índices compostos
2011/6/29 Dickson S. Guedes lis...@guedesoft.net: Em 29 de junho de 2011 12:27, Leandro DUTRA leandro.gfc.du...@gmail.com escreveu: 2011/6/28 Dickson S. Guedes lis...@guedesoft.net: Em tempo, tive bons contatos com ActiveRecord do Rails [2] […] bons contatos ali não foi no sentido de benéficos,[…] e sim no sentido de /alguem que leu e testou muitos codigos do ActiveRecord para compreender como ele funciona, para então pode auxiliar um ex-aluno em um projeto de TCC/ ... Ah, subitamente a realidade passa a fazer sentido! ;-) A questão na época era como melhorar a performance de duas aplicações em uso, sem tirar o HIbernate, tão pouco o ActiveRecord (do Rails). ¿Masoquismo? Ou sadismo, mesmo? Tem o caso da necessidade absoluta, também… Cara, é o fim do mundo. É a base opaca, não escalável, engessada. Mas isso já discutimos tanto, aqui e alhures… deixa quieto. […] Não sei como está hoje, mas até alguns meses atrás a aplicação estava lá, funcionando internamente e conforme o que desejavam. Funcionando eu creio… mas o modelo ficou opaco… -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Avaliando a ordem de colunas em índices compostos
2011/6/29 Dickson S. Guedes lis...@guedesoft.net: Em 29 de junho de 2011 18:54, Leandro DUTRA leandro.gfc.du...@gmail.com escreveu: Cara, é o fim do mundo. É a base opaca, não escalável, engessada. Mas isso já discutimos tanto, aqui e alhures… deixa quieto. […] Não sei como está hoje, mas até alguns meses atrás a aplicação estava lá, funcionando internamente e conforme o que desejavam. Funcionando eu creio… mas o modelo ficou opaco… Não tão opaco assim, pelo menos pra mim, pois eles tinham DOMAINs, CHECKs, FKs, UKs, PKs e até ENUMs bem definidos no PostgreSQL... e não chegavam a 10 PLs e sim, duplicaram as algumas regras na aplicação. Opa, acho que cortei demais o contexto… não estava falando de código procedural, que nada tem a ver com o modelo, mas de chaves artificiais generalizadas. Tudo bem que o uso sistemático de chaves naturais declaradas como alternativas evita o modelo opaco, mas aí as chaves artificiais criadas sistematicamente, e não ad hoc, representam um peso a mais para o sistema, que não é sempre necessário. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Avaliando a ordem de colunas em índices compostos
2011/6/28 Mozart Hasse mozart.ha...@usa.net: Índices devem primar pela seletividade Perfeitamente. Fábio, que te levou a dizer que deveríamos preferir primeiro os atributos com menor seletividade? Algum texto, testes? Para não dizer que a coisa é simples como parece — quase nunca é —, na verdade, os índices devem obedecer primeiro uma ordem baseada no uso. Assim, devem ficar na frente os atributos mais usados em diversas consultas, para que o índice possa ser usado pelas mais variadas consultas. Por exemplo, um índice ABC não será muito útil para uma consulta sobre BC, mesmo que A seja mais seletivo que B. Se as consultas BC forem significativas, será mais interessante BCA que ABC. Agora, se tanto consultas sobre BC quanto AB forem igualmente significativas, será mais interessante privilegiar AB, supondo que A seja mais seletivo que B, e avaliar a conveniência dum segundo índice, esse sobre BC. A questão que ainda resta aí é o que seria ‘significativo’. Basicamente, o que mais afeta os caminhos críticos do sistema, de acordo com seus requisitos. Porque isso só se pode saber ou com uma modelagem absurdamente perfeita do comportamento do sistema (aplicação, rede, base de dados, servidores, armazenamento, fase da Lua, incidência de neutrinos e umidade atmosférica na região c) ou, mais realisticamente, com testes. Em outras palavras, esses ‘devem’ que usamos (os índices ‘devem’ começar com os atributos mais seletivos, ou mais usados) são sempre relativos ao comportamento real do sistema. Portanto, não passam de regrinhas genéricas que nos conduzem a uma primeira implementação a testar, assim como nos ajudam a analisar os resultados dos testes. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Teste [nao abrir]
2011/6/28 Dickson S. Guedes lis...@guedesoft.net: Teste: não enviar… ; -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Silent Install Postgre 9.0
2011/6/28 Thaiz Rodrigues thaiz...@gmail.com:
Preciso fazer uma instalação silenciosa do postgres, fiz várias tentativas,
mas qq parâmetro que passo dá erro que o comando não é conhecido.
Segue meu último teste:
/qn --SERVICEACCOUNT=postgres --SUPERPASSWORD=teste --DATADIR={app}\data
--LISTENPORT=5432 --ENCODING=UTF-8
Sistema, resultado? Que erro, que plataforma(s)?
--
Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org
+55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803
sip:leand...@iptel.org 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] Sugestão de uso
2011/6/28 Shander Lyrio shan...@nucleo45.com.br: Flexibilidade de linguagem, mas SGDB engessado. Não necessariamente… o PostgreSQL implementa o SQL/PSM, que é o padrão ISO SQL para código ‘procedural’. Permite a migração para IBM DB2 e MySQL, pelo menos, que me lembre. Sem contar que dá para fazer em PL/PgSQL, caso em que dá para migrar para Oracle — não tão bem, por causa das idiossincrasias do Oracle. Claro que migrar sempre é mais fácil na teoria que na prática. Mas o PostgreSQL é, indubitavelmente, o SGBD que mais facilita migrar, tanto emigrar quanto imigrar. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Sugestão de uso
2011/6/28 Udlei Nattis mail...@nati.biz: A lógica de nosso sistema é bastante complexa e teremos uma série de programadores trabalhando em cima dele em diversos pontos. Imagina então quando o código for liberado... muitas pessoas vão trabalhar em cima dele simultaneamente o que aumenta a possibilidade de erros. Hm… deix’eu ver se intindi… Na verdade, tereis duas classes de programadores. Uma que criará vossos procedimentos, funções c — chamemo‐los programadores de sistema —; outra, que gerará as interfaces. Confiais nos programadores de sistema, que podeis ser vós mesmos, mas não nos de interfaces, que talvez sejam até trabalhadores temporários. Essa relação de confiança, creio, tem muito pouco a ver com o código de sistema estar na base de dados, num monitor de processamento de transações (vulgo ‘servidor de aplicações’), ou mesmo nas próprias interfaces, gráficas, textuais ou seja‐lá‐que‐for. Eu, particularmente, gosto da idéia de código de regras de negócio no servidor, mas principalmente na forma de restrições declarativas de integridade. O que não der para colocar na forma de restrições declarativas, mas for regra de negócio, creio que valha a pena colocar na forma de SQL/PSM ou algum equivalente, dos quais o PostgreSQL tem a maior variedade. Mas isso tem pouco a ver com a qualidade dos programadores ou a confiança neles, e tudo com a gestão do código de regras de negócio e restrições de integridade. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Avaliando a ordem de colunas em índices compostos
2011/6/28 Flavio Henrique Araque Gurgel fha...@gmail.com: Não se trata apenas de inverter a lógica, pois você teria agora de verificar quais colunas são mais utilizadas em cláusulas WHERE. Eu procuro fazer isso de duas formas, para sistemas já em produção: Informação é sempre bom, mas há limitações: 1) habilito consultas lentas no log (log_min_duration_statement = 1s por exemplo); analiso com o PgFouine e vou otimizando pouco a pouco. Há muitas situações em que o que pesa não são as consultas lentas, mas consultas rápidas e freqüentes. E não é por serem (relativamente) rápidas que não precisem de um carinho nos índices de quando em vez… 2) dou uma olhada na pg_statio_user_indexes e vejo como está o uso dos índices existentes; se algum índice composto tiver baixa taxa de uso, pode estar precisando de otimização ou remoção. Outra informação interessante, mas não fala muito sobre os índices que não existem e precisariam existir. Combinando essas duas informações dá para cobrir muito de muitos sistemas, mas não tudo. Para sistemas em implementação, se estiver usando um ORM, dá pra catar a lista de consultas pré-formatadas e trabalhar em cima delas. Se estiver usando ORM, dá para sentar na sarjeta e chorar… :-( -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Sugestão de uso
2011/6/28 Shander Lyrio shan...@nucleo45.com.br: Implementation of SQL/PSM is usually incomplete conforme [2]. Antes incompleto (PostgreSQL, DB2, Sybase, MySQL) que inexistente (Oracle, MS SQL Server c). -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Avaliando a ordem de colunas em índices compostos
2011/6/28 Flavio Henrique Araque Gurgel fha...@gmail.com: Sem dúvida! Mas um bom ponto de partida para otimizações é trabalhar sobre as consultas lentas, que são aquelas que os usuários percebem em um sistema. Então, nem sempre… há casos em que o problema é com consultas relativamente rápidas, mas executadas muito freqüentemente. Claro que uma otimização completa precisaria olhar todas as consultas, mas dependendo do sistema, isso pode ser excessivamente trabalhoso/caro de se fazer. Nunca fui tão fundo em PostgreSQL. Em Oracle, há toda uma instrumentação, por exemplo do cache SQL. Me lembro de ver uns exemplos com DTrace e PostgreSQL. Outra informação interessante, mas não fala muito sobre os índices que não existem e precisariam existir. Isso está coberto pela informação anterior (consultas lentas). Não necessariamente. Se estiver usando ORM, dá para sentar na sarjeta e chorar… :-( Nem sempre. ORMs podem ser bem utilizados. Pelo jeito, dei azar… nunca vi… pelo contrário, no mais comum — Hibernate — quem eu conheço que transmitia firmeza dizia que era contraproducente, tanto bem como mal utilizado. A grande exceção era aquele de Python, como se chamava? SQL alguma coisa ou algo SQL, mas até aí morreu o neves. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Surrogate Keys Can Become Natural Keys
2011/6/17 Charles Viana charles.vi...@gmail.com: http://momjian.us/main/blogs/pgblog/2011.html#June_16_2011 CQD, sempre repetimos aqui alhures. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] Estrutura de banco de dados fornecido por empresa terceirizada. Erros absurdos no meu ver, estou certo?
2011/6/13 Fabiano Machado Dias fabi...@wolaksistemas.com.br: Trabalho com sistemas ERP e posso te dizer que é impossível hoje em dia, uma empresa de médio-grande porte colocar as suas operações em uma contingência manual, pode me dar todos os argumentos do mundo, atualmente com NFe, Sped, FCont, e-Lalur, etc é vital que os sistemas estejam sempre online. Pois é… mas isso, em si, é um absurdo. Primeiro, porque decorre de um excesso de burocracia e complexidade da legislação. Conheci um livreiro em Lausanne que nem pagava imposto: ele simplesmente somava as faturas, e sempre dava abaixo do limite mínimo para pagamento. Aqui…? Segundo, o governo exige informatização sem ter viabilizado o uso de sistemas livres, impondo um custo indevido aos negócios. E essa inviabilidade tem dois aspectos: por um lado, o uso de sistemas livres no governo tem recuado (por exemplo, Câmara dos Deputados e Metrô de SP regrediram de ODF para MS Office); por outro, o ensino continua péssimo, o que tende a perpetuar a pirataria de Microsoft. E isso é uma coisa boa a meu ver, se não quebrasse nunca o paradigma ainda teríamos eleições com cédula (apesar de achar o nosso sistema falho), Eleições com cédulas são as únicas seguras, até hoje. Nem o mínimo de segurança temos, que seria a votação eletrônica mas com impressão e conferência pelo eleitor obrigatórias. entregaríamos o IR em formulário Seria melhor que ter de usar um programa proprietário. pagaríamos as contas só no balcão do caixa Non sequitur. Empresa com 2 mil funcionário existiam antes sim, mas existia um setor inteiro só para fazer a folha de pagamento, outro só para o financeiro, sem contar o fiscal e o contábil Já pensaram que, em países com mão de obra mal remunerada como o nosso, uma das causas de desemprego e da baixa remuneração é que o fracasso das políticas educacional, fiscal e normativa faz sair mais barato automatizar que empregar? hoje em dia é cada vez mais raro encontrar alguém que saiba, fazer as coisas no papel. E isso é péssimo… as empresas, na prática, não sabem funcionar sem fornecedores de sistemas, geralmente proprietários. Se ao menos soubessem o que acontece, seria viável, por exemplo, trocar de sistemas. -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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] - Dúvida sobre índice
2011/6/11 Euler Taveira de Oliveira eu...@timbira.com: Em 11-06-2011 03:43, Leandro DUTRA escreveu: no PostgreSQL a tabela pode ser agrupada http://doc.postgresqlfr.org/9.1/sql-cluster.html, e não o índice http://doc.postgresqlfr.org/9.1/sql-createindex.html. Ugh? O CREATE INDEX (aka REINDEX) faz exatamente a ordenação de um índice. É, estou enferrujado mesmo… -- Skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 Google Talk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ: AIM:GoIM?screenname=61287803 sip:leand...@iptel.org 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
