Le 12/09/12 0:37-0300, Fábio Telles Rodriguez a écrit :
Ou seja, concentrar toda inteligência no SGDB não é só um problema em
termos de portabilidade é um problema em termos de escalabilidade. Não
tem bala de prata neste mercado. Cada caso é um caso.
O que mostra que ainda não temos SGBDs
Em 11/09/2012 20:53, Jean Domingues escreveu:
Só pra apimentar a discussão, hoje programo com 90% da regra de negócio no
banco de dados (não interesse em portar pra outro banco). Pode ser não ser a
melhor alternativa, mas é bem rapido pra desenvolver.
Meu ponto de vista.
Você trabalha
Em 12/09/2012 06:45, Leandro Guimarães Faria Corcete DUTRA escreveu:
Le 12/09/12 0:37-0300, Fábio Telles Rodriguez a écrit :
Ou seja, concentrar toda inteligência no SGDB não é só um problema em
termos de portabilidade é um problema em termos de escalabilidade. Não
tem bala de prata neste
2012/9/12 Flávio Alves Granato flavio.gran...@gmail.com:
Uma ferramenta muito bem vinda, emendando com as novas características
do PostgreSQL 9.2 mais XC.
Justamente uma das limitações do XC hoje é não suportar tudo que o
PostgreSQL suporta — imagino que principalmente das versões mais
2012/9/11 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org:
Mas duvido que tenham mudado o problema principal [do hibernate],
que é tentar mapear objetos com tabelas.
Mas qual o problema? É certo que o mapeamento não é e nem tem como ser
um para um entre classes e tabelas, mas me parece
Em 12 de setembro de 2012 09:10, Joao Morais jcmorai...@gmail.comescreveu:
2012/9/11 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org:
Mas duvido que tenham mudado o problema principal [do hibernate],
que é tentar mapear objetos com tabelas.
Mas qual o problema? É certo que o
Em 12 de setembro de 2012 08:41, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
2012/9/12 Flávio Alves Granato flavio.gran...@gmail.com:
Uma ferramenta muito bem vinda, emendando com as novas características
do PostgreSQL 9.2 mais XC.
Justamente uma das limitações do
Pergunta, o RAC escala?
Bruno E. A. Silva.
Analista de Sistemas.
Bacharel em Sistemas de Informação
Pós-graduando em Gerência de Projetos
Certified Scrum Master
LPIC-1
SCJP, SE 6
Novell CLA / DCTS ECR
DBA Postgres
---
“A caixa dizia: Requer MS Windows ou superior.
Em 12 de setembro de 2012 10:26, Fábio Telles Rodriguez
fabio.tel...@gmail.com escreveu:
Em 12 de setembro de 2012 10:20, Bruno Silva bemanuel...@gmail.comescreveu:
Pergunta, o RAC escala?
Escala bem processamento. Em alguns casos (onde não houver hot blocks)
escala bem com memória. Mas o
Cara essa thread tá muito boa.
Bruno E. A. Silva.
Analista de Sistemas.
2012/9/12 Fabrízio de Royes Mello fabriziome...@gmail.com:
Em 12 de setembro de 2012 10:26, Fábio Telles Rodriguez
fabio.tel...@gmail.com escreveu:
Em 12 de setembro de 2012 10:20, Bruno Silva bemanuel...@gmail.com
"GF" == Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org writes:
GF Há pouquíssimos ORM que tenham um mínimo de qualidade.
GF Lembro do SQL Alchemy, do Python, e acho que o Diogo havia me dito que
GF o Rails estava com um decente opcional na versão três.
O DBIx::Class também é
2012/9/12 Joao Morais jcmorai...@gmail.com:
2012/9/11 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org:
Mas duvido que tenham mudado o problema principal [do hibernate],
que é tentar mapear objetos com tabelas.
Mas qual o problema?
O problema é que o equivalente de objeto é valor, e o
2012/9/12 Eden Cardim e...@insoli.de:
GF == Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org writes:
Há pouquíssimos ORM que tenham um mínimo de qualidade.
O DBIx::Class também é bastante razoável.
Bom saber. Mas não farei a justiça de investigar o por quê de ser razoável.
parte dos
2012/9/12 Bruno Silva bemanuel...@gmail.com:
Cara essa thread tá muito boa.
modéstia=off
Obrigado, obrigado…
modéstia=on
É que a lista tem gente muito boa…
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
2012/9/12 Fabrízio de Royes Mello fabriziome...@gmail.com:
E por acaso existe algo que escale disco automaticamente pra vc?
Qualquer coisa que não compartilhe disco… não há milagres. Hoje
temos, além da opção SSD, o Postgre XC que caminha para ser
distribuído — aliás minha memória parece
Em 12/09/2012 11:17, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2012/9/12 Eden Cardim e...@insoli.de:
GF == Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org writes:
Há pouquíssimos ORM que tenham um mínimo de qualidade.
O DBIx::Class também é bastante razoável.
Bom saber. Mas não
2012/9/12 Fábio Telles Rodriguez fabio.tel...@gmail.com:
Em 12 de setembro de 2012 08:41, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
Com a popularização do 9.2, mais escalável, e com os avanços nas
versões futuras tanto do PostgreSQL quanto do XC, logo o Fábio não
terá
"Joao" == Joao Morais writes:
Joao Mas qual o problema? É certo que o mapeamento não é e nem tem
Joao como ser um para um entre classes e tabelas, mas me parece
Joao claro que cada classe no modelo vira uma tabela no banco, que
Joao uma hierarquia de classes pode ter uma tabela para cada
Em 12/09/2012 11:12, Eden Cardim escreveu:
Joao == Joao Morais writes:
Joao Mas qual o problema? É certo que o mapeamento não é e nem tem
Joao como ser um para um entre classes e tabelas, mas me parece
Joao claro que cada classe no modelo vira uma tabela no banco, que
Joao uma hierarquia de
Pessoal, estou tendo o explain abaixo para uma view. O que não entendo é por
que o pg não está usando a chave primeira para fazer um join com a tabela de
compras (Seq Scan on compras c (cost=0.00..5125.69 rows=79569 width=26)).
Alguém pode me orientar?
Jean Domingues
QUERY PLAN
Sort
*Divulgado no blog também... Com certeza vai ser um sucesso.*
*
*
*Abraços.*
*
*Atenciosamente
_ _
*Fabiano Abreu*
*Papo Sql http://paposql.blogspot.com - Um blog com tutoriais, dicas e
truques sobre Sql
*
2012/9/12 Itamar Reis Peixoto ita...@ispbrasil.com.br
2012/9/12 Fábio Telles Rodriguez
Em 12/09/2012 s 12:09 horas, pgbr-geral-boun...@listas.postgresql.org.br escreveu:
Pessoal, estou tendo o explain abaixo para uma view. O que no entendo por que o pg no est usando a chave primeira para fazer um join com a tabela de compras (Seq Scan on compras c
#+BEGIN_EXAMPLE
GF == Guimarães Faria Corcete DUTRA, Leandro writes:
#+END_EXAMPLE
#+BEGIN_EXAMPLE
GF Mas aí é um problema ou de um modelo ruim (inconsistente), ou
GF incompleto (faltam as visões [VIEW]s que dêem os resumos que o
GF programa precisa) ou de um programa ruim. Ou de
Tá certo. Não passei por achar que era muita informação. Vamos lá:
1) a Tabela compras (a exemplo)
CREATE TABLE public.compras (
id BIGINT NOT NULL,
id_empresa INTEGER NOT NULL,
id_terceiro INTEGER NOT NULL,
num_ped_compra_interno INTEGER NOT NULL,
num_ped_compra INTEGER,
2012/9/12 Jean Domingues ejdom...@yahoo.com.br:
Tá certo. Não passei por achar que era muita informação. Vamos lá:
1) a Tabela compras (a exemplo)
CREATE TABLE public.compras (
id BIGINT NOT NULL,
[…]
Uma tabela tão grande assim provavelmente mistura várias entidades e
dificulta o
- Mensagem encaminhada -
De: Jean Domingues ejdom...@yahoo.com.br
Para: Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org
Enviadas: Quarta-feira, 12 de Setembro de 2012 14:27
Assunto: Re: [pgbr-geral] Interpretar explain
Dutra, ai vc me assusta. Apesar de a tabela ser grande, os
2012/9/12 Eden Cardim e...@insoli.de:
GF == Guimarães Faria Corcete DUTRA, Leandro writes:
GF Mas aí é um problema ou de um modelo ruim (inconsistente), ou
Metacomentário: que formato estranho! É padronizado algures?
Nem sempre, as vezes o domínio do negócio utiliza um formato mais
#+BEGIN_EXAMPLE
GF == Guimarães Faria Corcete DUTRA, Leandro writes:
#+END_EXAMPLE
#+BEGIN_EXAMPLE
GF O problema é que o equivalente de objeto é valor, e o equivalente de
GF classe é tipo de dados (abstrato).
#+END_EXAMPLE
Se você olhar pruma linguagem como OCaml, vai ver que isso nem
Me assusta ao dizer que ta complicado pro analisador. Bom, pra esses casos, o
Firebird me permitia informar o plano de execução junto a instrução select.
select plain (não lembro a sintaxe). No plain eu forçava o servidor a
usar o índice especificado para o join, ou para a where,
Em 12 de setembro de 2012 14:10, Jean Domingues
ejdom...@yahoo.com.br escreveu:
Tá certo. Não passei por achar que era muita informação. Vamos lá:
1) a Tabela compras (a exemplo)
CREATE TABLE public.compras (
id BIGINT NOT NULL,
id_empresa INTEGER NOT NULL,
id_terceiro INTEGER NOT
Em 12/09/2012 s 14:39 horas, pgbr-geral-boun...@listas.postgresql.org.br escreveu:
(...)
FROM nfe
LEFT JOIN compras c ON c.id = nfe.id_compra
LEFT JOIN vendas v ON v.id = nfe.id_venda
LEFT JOIN terceiros t1 ON nfe.id_terceiro = t1.id
LEFT JOIN naturezas_operacoes nop1 ON
De: Marcone marconepe...@gmail.com
Para: Jean Domingues ejdom...@yahoo.com.br; Comunidade PostgreSQL Brasileira
pgbr-geral@listas.postgresql.org.br
Enviadas: Quarta-feira, 12 de Setembro de 2012 14:52
Assunto: Re: [pgbr-geral] Interpretar explain
Em 12 de
Em 12 de setembro de 2012 14:10, Jean Domingues
ejdom...@yahoo.com.br escreveu:
Tá certo. Não passei por achar que era muita informação. Vamos lá:
1) a Tabela compras (a exemplo)
CREATE TABLE public.compras (
id BIGINT NOT NULL,
(corte)
Eu diria que, se o produto da consulta sobre a
#+BEGIN_EXAMPLE
FG == Flávio Alves Granato writes:
#+END_EXAMPLE
#+BEGIN_EXAMPLE
FG Teria com colocar um exemplo simples? Pq agora eu fiquei bem confuso...
FG até consigo entender mas não visualizar em minhas rotinas diárias...
#+END_EXAMPLE
Um problema recorrente, por exemplo, é
2012/9/12 Flávio Alves Granato flavio.gran...@gmail.com:
Lendo os artigos enviados pelos amigos, eu trocaria
tabelas/registro/dominio e classes/objetos/Tipos. Estou certo?
Não entendi o que seria essa troca?
___
pgbr-geral mailing list
Em 12/09/2012 15:10, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2012/9/12 Flávio Alves Granato flavio.gran...@gmail.com:
Lendo os artigos enviados pelos amigos, eu trocaria
tabelas/registro/dominio e classes/objetos/Tipos. Estou certo?
Não entendi o que seria essa troca?
Não se preocupe,
2012/9/12 Joao Morais jcmorai...@gmail.com:
me parece claro que cada
classe no modelo vira uma tabela no banco
Não. O conceito de classe corresponde a tipo, não tabela (relação).
Pode haver um tipo relação (tabela), mas a correspondência é via tipo.
Isso porque a relação é transparente, ao
Senhores,
Fiquei curioso se existe uma comparação em algum lugar indicando o quê o
nosso querido SGBD ainda não tem e que poderia estar sendo feito ou
planejado, algo como o roadmap para alinhar o SGBD ao modelo relacional
e/ou à última versão do padrão SQL.
Abraços,
Flávio Granato
2012/9/12 Eden Cardim e...@insoli.de:
Um problema recorrente, por exemplo, é transformar isso:
[…]
| 1 | 1 |
| 1 | 2 |
| 1 | 3 |
Em isso (JSON):
{1:[1,2,3]}
Mas isso não é abstração… ou perdi algo?
___
pgbr-geral mailing list
Em 12 de setembro de 2012 15:03, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
Mudar a ordem dos JOINs pode ajudar.
..
corte
.
Tente reescrever sua consulta trocando a ordem dos JOINs. Se possível, use
INNER JOIN onde puder.
Sobre os filtros, com tabelas associadas e
2012/9/12 Flávio Alves Granato flavio.gran...@gmail.com:
Fiquei curioso se existe uma comparação em algum lugar indicando o quê o
nosso querido SGBD ainda não tem e que poderia estar sendo feito ou
planejado
Existe o TODO http://wiki.postgresql.org/wiki/Todo.
algo como o roadmap para
>Flávio, com todo respeito que lhe cabe, trocar a ordem dos [left |
>inner] joins não adianta, o otmizador já "faz" isso.
>Trocar de left para inner aí sim, fará diferença, nesse ponto concordo com você.
Com todo o respeito à comunidade que escreve o querido *manual* :)
On 12-09-2012 15:21, Flávio Alves Granato wrote:
Fiquei curioso se existe uma comparação em algum lugar indicando o quê o
nosso querido SGBD ainda não tem e que poderia estar sendo feito ou
planejado, algo como o roadmap para alinhar o SGBD ao modelo relacional
e/ou à última versão do padrão
Em 12 de setembro de 2012 15:40, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
Com todo o
respeito à comunidade que escreve o querido *manual* :)
http://www.postgresql.org/docs/9.2/static/explicit-joins.html Tá
explicadinho como é possível fazer algumas melhorias em planejamento
Em 12 de setembro de 2012 15:23, Marcone marconepe...@gmail.com escreveu:
Em 12 de setembro de 2012 15:03, Flavio Henrique Araque Gurgel
fla...@4linux.com.br escreveu:
Mudar a ordem dos JOINs pode ajudar.
..
corte
.
Tente reescrever sua consulta trocando a ordem dos JOINs. Se
On 12-09-2012 14:10, Jean Domingues wrote:
Tá certo. Não passei por achar que era muita informação. Vamos lá:
Além das tabelas e índices envolvidos faltou o 'EXPLAIN ANALYZE consulta'. Um
simples 'EXPLAIN consulta' não diz muita coisa porque ele *não* executa a
consulta; o EXPLAIN ANALYZE
2012/9/12 Flávio Alves Granato flavio.gran...@gmail.com:
Você trabalha quebrando um conceito que é o SoC ( Separation of Concerns
), basicamente cada macaco no seu galho.
Mas esse conceito não é válido aqui. Como ele se aplicaria ao caso?
Parece mais uma regrinha generalizada…
Me baseio
Pessoal,
estou postando o resultado para a lista. A única mudança que fiz na view foi
trocar o left por join em 2 pontos abaixo, que são campo do tipo not null em
nfe, como demonstrado abaixo:
FROM nfe
LEFT JOIN compras c ON c.id = nfe.id_compra
LEFT JOIN vendas v ON v.id =
2012/9/12 Jean Domingues ejdom...@yahoo.com.br:
Não caberia aqui alguma melhoria no algorítimo do otimizador?
Esse planejador está tão maduro que provavelmente faltou foi entender
o que aconteceu… mas o SQL não é poderoso o suficiente, isso exige uma
certa complexidade e o planejador às vezes
Em 12/09/2012 15:57, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2012/9/12 Flávio Alves Granato flavio.gran...@gmail.com:
Você trabalha quebrando um conceito que é o SoC ( Separation of Concerns
), basicamente cada macaco no seu galho.
Mas esse conceito não é válido aqui. Como ele se
Em 12/09/2012 15:44, Euler Taveira escreveu:
On 12-09-2012 15:21, Flávio Alves Granato wrote:
Fiquei curioso se existe uma comparação em algum lugar indicando o quê o
nosso querido SGBD ainda não tem e que poderia estar sendo feito ou
planejado, algo como o roadmap para alinhar o SGBD ao
Em 12 de setembro de 2012 16:12, Jean Domingues
ejdom...@yahoo.com.br escreveu:
A única mudança que fiz na view foi trocar o left por join em 2 pontos
abaixo, que são campo do tipo not null em nfe, como demonstrado abaixo:
- Index Scan
GF == Guimarães Faria Corcete DUTRA, Leandro writes:
GF Mas isso não é abstração… ou perdi algo?
É um processo abstraível sim… E é exatamente o ponto onde eu quero chegar. Não
tem porque reimplementar essa transformação quando você pode abstrair isso com
uma biblioteca e economizar
- Mensagem original -
De: Marcone marconepe...@gmail.com
Para: Jean Domingues ejdom...@yahoo.com.br; Comunidade PostgreSQL
Brasileira pgbr-geral@listas.postgresql.org.br
Cc:
Enviadas: Quarta-feira, 12 de Setembro de 2012 16:22
Assunto: Re: [pgbr-geral] Interpretar explain
Em
2012/9/12 Flávio Alves Granato flavio.gran...@gmail.com:
Mas para mim,
A frase veio truncada…
Vale lembrar que hoje
SGDB já considerando LEGADO advento do NoSql.
O que mostra que o autor é uma toupeira no que se refere a dados, além
de não saber escrever.
Não tem necessidade dessa
2012/9/12 Eden Cardim e...@insoli.de:
Não tem porque reimplementar essa transformação quando você pode abstrair
isso com uma biblioteca e economizar com a implementação. É onde um ORM
(ressaltando que não gosto dessa terminologia) decente pode trazer
benefício.
Mas essa transformação não tem
De: Marcone marconepe...@gmail.com
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
Enviadas: Quarta-feira, 12 de Setembro de 2012 15:52
Assunto: Re: [pgbr-geral] Interpretar explain
Em 12 de setembro de 2012 15:40, Flavio Henrique
JSON não é orientado mesmo. E sinceramente, pode ser ótimo pro
desenvolvedor no momento que tá criando. Fico imaginando a manutenção
disso uns 3 anos depois, o cara olha o código e vê lá { '1', { sdfsd
,dsf s },{ sdf123,} }
Bruno E. A. Silva.
Analista de Sistemas.
2012/9/12 Guimarães Faria
2012/9/12 Bruno Silva bemanuel...@gmail.com:
JSON não é orientado mesmo. E sinceramente, pode ser ótimo pro
desenvolvedor no momento que tá criando. Fico imaginando a manutenção
disso uns 3 anos depois, o cara olha o código e vê lá { '1', { sdfsd
,dsf s },{ sdf123,} }
Ô saudades dos arquivos
Entendi... e faz sentido. Valew.
- Mensagem original -
De: Marcone marconepe...@gmail.com
Para: Jean Domingues ejdom...@yahoo.com.br
Cc:
Enviadas: Quarta-feira, 12 de Setembro de 2012 17:06
Assunto: Re: [pgbr-geral] Interpretar explain
Marcone, só frisando o seguinte: a
Éguas Dutra, eu nunca cheguei a trabalhar diretamente, mas depois de
ver o cara usar a calculadora pra definir o tamanho do arquivo a ser
alocado, vi que a coisa era complicada!
Bruno E. A. Silva.
Analista de Sistemas.
Bacharel em Sistemas de Informação
Pós-graduando em Gerência de Projetos
2012/9/12 Marcone marconepe...@gmail.com:
Em 12 de setembro de 2012 16:12, Jean Domingues
ejdom...@yahoo.com.br escreveu:
Não caberia aqui alguma melhoria no algorítimo do otimizador?
A meu ver não. O comportamento está dentro do esperado. Já que você
usou inner join as linhas retornadas em
2012/9/12 Bruno Silva bemanuel...@gmail.com:
Éguas Dutra, eu nunca cheguei a trabalhar diretamente, mas depois de
ver o cara usar a calculadora pra definir o tamanho do arquivo a ser
alocado, vi que a coisa era complicada!
Nada, era a própria simplicidade… cheio de limitações e ineficiências,
GF == Guimarães Faria Corcete DUTRA, Leandro writes:
GF Metacomentário: que formato estranho! É padronizado algures?
Meta-resposta: Existe padrão de resposta de email sancionado por
alguma organização relevante?
GF Não, é só ter o tipo adequado. E o PostgreSQL nos permite criar
Em 12 de setembro de 2012 17:16, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
2012/9/12 Bruno Silva bemanuel...@gmail.com:
Éguas Dutra, eu nunca cheguei a trabalhar diretamente, mas depois de
ver o cara usar a calculadora pra definir o tamanho do arquivo a ser
alocado,
De: Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
Enviadas: Quarta-feira, 12 de Setembro de 2012 17:14
Assunto: Re: [pgbr-geral] Interpretar explain
2012/9/12 Marcone
GF == Guimarães Faria Corcete DUTRA, Leandro writes:
GF Mas essa transformação não tem nada a ver com ORM!
Não tem se você não quiser enxergar dessa forma. Mas é perfeitamente razoável
usar um ORM como um transformador resultset - JSON (ou XML, ou CSV, ou
tabulado, ou SVG, etc.),
Regarding Re: Substituição dos ORM; Bruno Silva
bemanuel...@gmail.com adds:
BS JSON não é orientado mesmo. E sinceramente, pode ser ótimo pro
BS desenvolvedor no momento que tá criando. Fico imaginando a manutenção
BS disso uns 3 anos depois, o cara olha o código e vê lá { '1', {
Em 12 de setembro de 2012 16:37, Eden Cardim e...@insoli.de escreveu:
GF == Guimarães Faria Corcete DUTRA, Leandro writes:
GF Metacomentário: que formato estranho! É padronizado algures?
Meta-resposta: Existe padrão de resposta de email sancionado por alguma
organização relevante?
2012/9/12 Jean Domingues ejdom...@yahoo.com.br:
De: Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org
Se o retorno é o mesmo, os planos não são equivalentes? Se são
equivalentes, não é uma questão do custo de analisar essas possíveis
equivalências?
Dutra, o retorno é igual. Mas, como o
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
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
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!:
TA == Tiago Adami writes:
TA Sancionado não, mas existe uma etiqueta, ou netiqueta [1], que
TA remete à RFC 1855 [2]. Realmente, teus e-mails estão difíceis de ler.
TA Até essa criação de índices para os autores das frases foi criativo,
TA mas estranho.
Esse formato com iniciais
Olá senhores, alguma alma caridosa poderia me ajudar a resolver essa
questão? Não precisa ser a solução, pode ser algo para leitura. Já quebrei
cabeça aqui e não consigo chegar numa solução.
Preciso somar todos os valores de uma coluna em circunstâncias diferentes na
mesma cláusula SQL. Para
Veja CASE
em http://www.postgresql.org/docs/9.1/static/functions-conditional.html
De: Eduardo Almeida edua...@web2solutions.com.br
Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br
Enviadas: Quarta-feira, 12 de Setembro de 2012
Veja CASE em
http://www.postgresql.org/docs/9.1/static/functions-conditional.html
Opa, obrigado!
De: Eduardo Almeida edua...@web2solutions.com.br
Para: Comunidade PostgreSQL Brasileira
pgbr-geral@listas.postgresql.org.br
Enviadas: Quarta-feira, 12 de
On 12-09-2012 23:28, Eduardo Almeida wrote:
Olá senhores, alguma alma caridosa poderia me ajudar a resolver essa
questão? Não precisa ser a solução, pode ser algo para leitura. Já quebrei
cabeça aqui e não consigo chegar numa solução.
Preciso somar todos os valores de uma coluna em
Veja CASE em
http://www.postgresql.org/docs/9.1/static/functions-conditional.html
Jean, mas CASE seria para retornar um valor quando uma condição for
satisfeita ... realmente não vi como fazer isso usando CASE .. mas obrigado
De: Eduardo Almeida
LD == Leandro DUTRA, Guimarães Faria Corcete writes:
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,
Não entendi a dificuldade. Será que entendi sua pergunta corretamente?
Vê se é isso...
Aliás, sua consulta original tem erro. Você não deve agrupar por total
porque é a coluna que você tá consolidando. E não dá pra agrupar por
data_do_recebimento porque não tá listada no SELECT, aí seu
Em 12/09/12, Eduardo Almeidaedua...@web2solutions.com.br escreveu:
Veja CASE em
http://www.postgresql.org/docs/9.1/static/functions-conditional.html
Jean, mas CASE seria para retornar um valor quando uma condição for
satisfeita ... realmente não vi como fazer isso usando CASE .. mas obrigado
-Original Message-
From: Bruno Silva
Sent: Saturday, September 08, 2012 1:41 AM
To: Comunidade PostgreSQL Brasileira
Subject: Re: [pgbr-geral] Postgres 9.1 + VB6
Verificamos que tem relação com o fato dele atualizar dados em
consultas usando INNER JOIN.
Conseguiu resolver Bruno? Já tive
83 matches
Mail list logo
