Re: [pgbr-geral] "orientado a banco de dados"

[Tiago José Adami]

Em 3 de janeiro de 2018 10:13, Samuel Teixeira Santos
 escreveu:
>
> Bom dia pessoal, feliz 2018 a todos.
>
> Sou novo na lista e meu perfil é de desenvolvedor (para entenderem o porque 
> da minha pergunta abaixo... tentando justificá-la )
>
> Estou na faixa de conhecimento que vai do básico para intermediário em 
> relação a banco de dados e me interesso mais pela perfil técnico de banco de 
> dados do que da modelagem/administração de dados.
>
> Por isso, gostaria de bater um papo, ler o que vocês sabem ou acham sobre 
> casos, se já viram algum, em que foi-se construída uma aplicação que tinha 
> toda sua inteligência no banco de dados, podendo facilitar a desacoplagem da 
> camada do cliente de forma menos trabalhosa e associando a outras tecnologias 
> desta camada conforme a necessidade.
>
> Já viram algo do tipo? Recomendam tal abordagem?
>
> Por exemplo, hoje uma aplicação WEB, você desenvolve a camada 
> cliente(browser: html/css/js), desenvolve o backend (apache/nginx/tomcat - 
> php/python/java) e ainda mais específico, a camada do banco de dados.
>
> A idéia é continuar desenvolvendo a camanda cliente (porque não há como fugir 
> dela no casa da plataforma web), mas minimizar o possível a camada do server, 
> deixando-a apenas para o repasse de dados para o banco e a chamada de 
> procedures e functions no mesmo, onde realmente existirá o processamento 
> total dos dados, as regras de negócio etc
>
> Na experiência de vocês, já viram algo? Já tentaram algo do tipo?
>
> O que acham desta abordagem?
>
> Chamei-a no título de "orientado a banco de dados" com aspas porque realmente 
> não sabia como titular de outra forma menos redundante, ou com pleonasmo, não 
> sei.
>
> Espero poder muito aprender com vocês, independente do que eu expus aqui ser 
> viável ou não.

Olá, Samuel.

Esta abordagem existe principalmente em sistemas fechados que
requisitam alto nível de segurança e integração entre diversos
clientes (agentes/softwares e interfaces). Um exemplo que posso citar
- e com os quais trabalhei - são sistemas bancários. Quando trabalhei
como analista/programador para o extinto HSBC Brasil há mais de 10
anos, praticamente todos os aplicativos continham somente a interface,
todas as regras de negócio estavam em stored procedures e funções
dentro de bancos de dados Oracle e Sybase.

Existem várias questões a serem consideradas ao utilizar todas as
regras de negócio no banco da dados. É preciso elencar os _pros_ e
_contras_ de tal implementação. Algumas que posso citar:

Pros:
- Maior desempenho;
- Possibilidade de compartilhar regras de negócio sem a necessidade de
um servidor de aplicações;
- Menor complexidade com todas as regras centralizadas (um pouco subjetivo);
- Maior integração com recursos do banco de dados (travas/locks de
registros, cursores, etc.);
- Segurança, pois o banco de dados _deve_ ser uma _caixa fechada_ com
pouco acesso;

Contras:
- Se você pretende usar mais de um _vendor_ ou produto (PostgreSQL,
Oracle, DB2, etc.), reutilizará pouco código entre os diferentes
bancos de dados;
- Requer mão de obra qualificada para programar no banco de dados, até
certo ponto escassa, haja vista que há muitos programadores
Java/Python/.Net/RoR/etc. e poucos que conhecem realmente SQL e as PL
dos SGBDRs;
- As atualizações de regras de negócio _geralmente_ demandam um
downtime maior e que afeta todos os usuários, diferente da atualização
de servidores de aplicação distribuídos;
- Se o banco de dados fica no cliente (customer), todas as regras de
negócio ficam visíveis, então se você pretende fechar seu código 100%,
esta não seria uma boa opção;
- É mais difícil convencer Gerentes de Projeto e patrocinadores porque
há um argumento _falho_ de que pode ser preciso trocar o SGBD no
futuro, mantendo independencia de tecnologia, o que quase nunca
acontece (por minha experiência);


Elencar pros e contras é um pouco subjetivo. Eu sou fã desta abordagem
por já ter visto que funciona muito bem. Mas você irá encontrar mil e
um argumentos favoráveis e desfavoráveis a ela conforme a experiência
de cada um.


Tiago J. Adami
http://www.powerdba.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Migrando para Postgres

[Tiago José Adami]

Olá.

Em 10 de outubro de 2017 02:15, centrisco...@gmail.com
 escreveu:
>
> Agradeço a todos pelas suas respostas.
>
> O Firebird não é um banco ruim. É fácil e até gostoso de se trabalhar com 
> ele. Tenho notado que em algumas situações ele acaba ficando pra trás.
> A começar pelo material. Tem muita coisa na web, tutoriais, vídeos sobre o 
> Postgres do que para Firebird.
>
> Vou seguir a dica do Marcos. Ir migrando como está e aprender com isso. Eu 
> vejo que essa é a parte mais fácil. Difícil é convencer teu cliente a mudar 
> de banco sendo que o mesmo o tem servido por uns 10 anos.

Migração de banco de dados envolve custos que muitas vezes não estão
muito explícitos, como qualificação da equipe de desenvolvimento e
sustentação. Além disto, você terá que reescrever funções, triggers,
views e outros objetos, além de readaptar instruções na sua aplicação
quando são usadas funções de banco.

Firebird não é um banco ruim, de fato, principalmente se usado em
aplicações que precisam de um banco de dados embarcado. O PostgreSQL é
muito mais robusto e resiliente, com mais funcionalidades, mas não foi
projetado para ser embarcado em aplicações - isso já foi discutido
várias vezes aqui na lista e já tenho experiência de ter trabalhado em
algumas empresas que tentaram fazer isso e criaram _monstros_ difíceis
de manter.

Se você hoje usa Firebird e pretende migrar para o PostgreSQL em uma
arquitetura cliente/servidor ou mesmo em várias camadas, isto é,
quando o banco de dados está em um servidor separado (não-embarcado),
você terá ganhos com escalabilidade no futuro quando o seu banco de
dados ter um tamanho considerável (vamos chutar, mais de 100 GB).

Já um banco de dados com 5 GB é ínfimo para qualquer SGBDR _que se
preze_, então não espere ganhos absurdos de desempenho somente por
mudar para o PostgreSQL neste momento.

Dependendo de como é sua aplicação, não compensa. Elucide corretamente
os recursos que existem no PostgreSQL que você pode se beneficiar
antes de migrar.


Tiago J. Adami
http://www.powerdba.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PostgresSQL não iniciando no windows 10

[Tiago José Adami]

Em 28 de setembro de 2017 19:55, Junior Miranda
 escreveu:
>
> Boa noite a todos!
>
> Estou enfrentando problemas na inicialização do postgresSQL 9.4 no windows 
> 10. É algo que  tem ocorrido ocasionalmente, ou seja, há dias em que os 
> cliente ligam seus pcs e o servidor inicia normalmente e dias que na primeira 
> tentativa não inicia, precisando reiniciar o pc. Já olhei a questão de 
> permissão, se havia o warsaw instalado, apaguei pID etc. Mas infelizmente 
> ainda ocorre. Alguém que já tenha passado por situação similar com o windows 
> 10??
>

Olá!

Sim, já presenciei isso no meu notebook com Windows 10, antes de eu
trocar o HDD por uma unidade SSD.

O serviço de rede e RPC que o PostgreSQL depende demoravam a ser
carregados completamente, e isso fazia com que a inicialização do
serviço do PostgreSQL falhasse. Era nítido porque o gargalo estava no
disco, o Windows 10 tem dezenas de serviço que iniciam automaticamente
durante o boot (sic!).

Altere o serviço do PostgreSQL para o tipo de inicialização
"Automático (atraso na inicialização)" que deve resolver. Caso
contrário, verifique o log do PostgreSQL e os logs de eventos do
Windows e nos informe os motivos pelos quais ele não foi carregado.


Tiago J. Adami
PowerDBA
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Transferir Banco Postgres para outra máquina

[Tiago José Adami]

Em 24 de junho de 2017 21:19, Euler Taveira  escreveu:
> Em 24 de junho de 2017 16:26, Luiz Henrique 
> escreveu:
>>
>>
>> Desejo transferir de forma definitiva.
>
>
> Uma das formas mais rápidas seria utilizando replicação. Para isso o
> hardware/SO deve ser (quase) igual. Uma vez montada a replicação [1], basta
> escolher uma janela de manutenção e fazer o failover (pg_ctl promote).
>
>
> [1] http://eulerto.blogspot.com.br/2017/02/replicacao-o-que-mudou.html

Outras opções não tão rápidas e talvez mais simples:

O OP está usando a versão 9.1. Se quiser mantê-la sejam quais forem
seus motivos (não recomendado), IMHO eu bloquearia todas as conexões
não administrativas de aplicativos para evitar novas informações
deixando somente a conexão local do postgres e faria um backup com
pg_basebackup (não dump [1][2]).

Caso contrário, se for uma migração definitiva para a versão atual 9.6
(recomendado), eu usaria o pg_dump mesmo. Vai demorar um ou dois dias
de acordo com o relato do OP, mas traria o benefício imediato de fazer
um upgrade.

[1] https://savepoint.blog.br/2010/05/06/dump-nao-e-backup/   -->
Não me canso de citar este artigo
[2] https://www.postgresql.org/docs/9.1/static/app-pgbasebackup.html

Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Transferir Banco Postgres para outra máquina

[Tiago José Adami]

Em 23 de junho de 2017 13:56, Luiz Henrique
 escreveu:
> Mestres!
>
> Gostaria de dicas/sugestões de como transferir Banco Postgres para outra
> máquina.
> Segue detalhes
>
> Ambiente Linux CentOS 6
> Postgres 9.1
> Somente 1 Database, tamanho 415 GB
> Peculiaridade : 95% desse tamanho são binários de arquivos anexados ao banco
> Atualmente o pg_dump leva 22h para terminar
>
> Eu preciso transferir esse banco (no menor tempo possível) para outro
> equipamento similar.
>
> Favor sugerir dicas da melhor forma que os senhores indicam
>
> 1 - pg_dumpall - pg_restore ?
> 2 - recursos de replicação ?
> 3 - rsync ?
> 4 - outros métodos ???
>

Você quer transferir o banco de dados permanentemente uma única vez ou
manter uma cópia atualizada em outro local/servidor?

Tiago J. Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ajuda com o Query Planner

[Tiago José Adami]

Em 22 de junho de 2017 20:57, Marcelo Costa  escreveu:
>
> Pessoal,
>
> Alguém que saque de query planner pra ajudar?
>
> Quero entender pq ele roda um planner global ao invés de parciais.
>
> Minha query:
>
> select count(*) from table1 where time > (select time from table2 where X = Y)
>
> O PG está fazendo uma seqscan na table1 mesmo que a coluna time seja uma 
> coluna indexada.
>
> Mas ele usa o indice se eu faço:
>
> select count(*) from table1 where time > 1498083552
>
> Então meu problema é que, como ele não sabe o valor de filtragem de time, na 
> duvida manda fazer seqscan.
>
> Pergunta:
>
> Existe alguma forma de mandar ele rodar o query planner por etapas?
>
> Primeiro pra subquery e depois pra query principal?
>

Com CTE você consegue este comportamento. Tenta isto:

WITH table2cte (time) AS (
select time from table2 where X = Y
)
select count(*) from table1, table2cte where time > table2cte.time


Tiago J. Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Conteúdo de logs para arquivo CSV

[Tiago José Adami]

Em 10 de maio de 2017 11:16, Sebastian Webber  escreveu:
>
>
> Roda no psql:
>
>
> \x
> select * from pg_settings where name = 'log_destination';

Bingo!

Agradeço, Sebastian. Alguém criou um arquivo adicional em
data/conf.d/production.conf (agora começa a caça às bruxas) e com o
retorno deste comando eu o encontrei.

Falhei em não lembrar de procurar outro arquivo fazendo _override_ das
configurações.

Agora já está resolvido. Muito obrigado!

Este foi o retorno:

  name   | setting | unit |   category
  | short_desc  |
  extra_desc
 | context | vartype |
source   | min_val | max_val | enumvals | boot_val | reset_val |
sourcefile| sourceline
-+-+--+--+-+--
-+-+-++-+-+--+--+---+-+
 log_destination | csvlog  |  | Reporting and Logging / Where to
Log | Sets the destination for server log output. | Valid values are
combinations of "stderr", "syslog", "csvlog", and "e
ventlog", depending on the platform. | sighup  | string  |
configuration file | | |  | stderr   | csvlog
  | /pgsql/data/conf.d/production.conf  | 13
(1 row)


Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Conteúdo de logs para arquivo CSV

[Tiago José Adami]

Bom dia!

Em um servidor na Amazon rodando PostgreSQL 9.4.9 apresenta um
comportamento estranho - ao menos para mim: ao invés de gravar todo o
conteúdo em um arquivo com extensão "log", um arquivo sem extensão é
criado com tamanho 0 bytes e tudo é redirecionado para um outro
arquivo com extensão "csv".

Não devo estar percebendo corretamente o valor de alguma configuração,
mas tenho outros servidores com os mesmos parâmetros (aparentemente) e
estão armazenando os logs corretamente.

Alguém poderia revisar minhas configurações, por gentileza?


log_destination = 'stderr'
logging_collector = on
log_directory = '/pg_log'
log_filename = 'postgresql-%a.log'
log_truncate_on_rotation = on

client_min_messages = log
log_min_messages = warning

log_min_error_statement = error
log_min_duration_statement = 1
log_connections = on
log_disconnections = on
log_lock_waits = on
log_timezone = 'UTC'


Lista de arquivos na pasta /pg_log de hoje:

-rw--- 1 postgres postgres  402K May 10 14:04 postgres-2017-05-10_00.csv
-rw--- 1 postgres postgres 0 May 10 00:00 postgres-2017-05-10_00



TIAGO J. ADAMI
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Database is in recovery mode

[Tiago José Adami]

Em 20 de abril de 2017 18:10, Fabrízio de Royes Mello
 escreveu:
> Isso é por conta do "overcommit_ratio = 50" que indica que foi solicitado 
> alocar mais memória que o "total de swap + 50% da RAM" [1] ... como vc nao 
> tem swap entao ele tentou alocar mais que RAM/2 e o kernel matou...
>
> Att,
>
>
> [1] https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

Agradeço pela ajuda, Fabrízio.

Inicialmente fiquei confuso porque no /var/log/messages não haviam
entradas do OOM Killer. Mas durante a redação da resposta eu fui
conferir se havia algo desta vez e lá estava o registro.

Sobre o problema: não estava exatamente no overcommit_ratio = 50 [1]
porque o outro parâmetro overcommit_memory estava no padrão heurístico
- valor 0. A realidade era que o servidor estava no limite de
utilização de memória. O total de memória em cache passou a ser
reduzido a meros 1 ou 2 GBs pouco antes do OOM entrar em ação.

Com mais de 96 conexões ativas e executando comandos SQL sem parar, em
um momento os 16 GB de memória RAM chegaria no limite. A solução
encontrada foi criar uma partição SWAP de 10 GB. Tão logo foi criada,
passou a ser preenchida em até 30% nos momentos de maior utilização,
sendo liberada nos momentos de "bonanza".

Achei um artigo convincente que dá detalhes de como funcionam estes
parâmetros do Kernel [2] dando exemplos, mas baseando-se na
configuração overcommit_memory=2, o que limita de forma parametrizada
o total que um processo pode alocar além do limite real.

Talvez já esteja entrando em uma nova thread, mas quando falamos de um
servidor dedicado do PostgreSQL, qual seria a recomendação? Tunar o
overcommit conforme mostra o artigo [2] ou manter os padrões?

[1] https://www.kernel.org/doc/Documentation/sysctl/vm.txt
[2] 
http://engineering.pivotal.io/post/Virtual_memory_settings_in_Linux_-_The_problem_with_Overcommit/

TIAGO J. ADAMI
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Database is in recovery mode

[Tiago José Adami]

Em 20 de abril de 2017 17:12, Fabrízio de Royes Mello
<fabri...@timbira.com.br> escreveu:
> Em 20 de abril de 2017 15:35, Tiago José Adami <adam...@gmail.com> escreveu:
>>
>> Boa tarde a todos.
>>
>> Tenho um servidor na Amazon com PostgreSQL 9.4.9 64-bit instalado, lá
>> roda uma versão do Fedora modificada.
>
> Nem preciso te dizer que deves atualizar pra 9.4.11...

Sabia que a primeira coisa que me diriam seria para atualizar ;)

E concordo plenamente, mas a instalação é do repositório oficial da
Amazon que está desatualizado. Por enquanto uma GMUD para incluir
outro repo ainda não foi discutida.

>> (...)
>> WARNING,57P02,"terminating connection because of crash of another
>> server process","The postmaster has commanded this server process to
>> roll back the current transaction and exit, because another server
>> process exited abnormally and possibly corrupted shared memory.","In a
>> moment you should be able to reconnect to the database and repeat your
>> command."
>> (...)
>
> Só tem essa informação no LOG?? Essa informação que vc pegou não é a causa e
> sim o efeito... vasculhe seu log por mais informações.

Estou vasculhando pela 3a vez os logs, mas não há nenhuma informação
adicional. Estas mensagens ocorre logo após a execução de um SQL
SELECT qualquer.


>> Nas minhas pesquisas e até onde vai meu conhecimento isto ocorre com
>> problemas de hardware, em especial, memórias (lembro-me do tempo do
>> PostgreSQL 7.4 rodando em servidores com pentes de memória de
>> velocidade e latências diferentes).
>>
>> Mas levando em consideração que o servidor está na Amazon... o que
>> mais poderia estar causando este erro? Algum palpite?
>>
>
> Eu arrisco que vc pode estar passando por algum "overcommit_memory" ou coisa
> parecida. Esse linux tem swap e como está o overcommit_memory?

O OOM e overcommit estão com os valores padrão

vm.oom_dump_tasks = 1
vm.oom_kill_allocating_task = 0
vm.overcommit_kbytes = 0
vm.overcommit_memory = 0
vm.overcommit_ratio = 50

O servidor não tem Swap.

Estava quase enviando o e-mail quando fui checar novamente o
/var/log/messages. Agradeço também ao colega Felipe Pereira (obrigado
pelas dicas), desta vez encontrei a causa mortis:

Apr 20 18:00:47 ip-172-16-4-27 kernel: [238117.075735] Killed process
2485 (postmaster) total-vm:2124064kB, anon-rss:272232kB, file-rss:4kB,
shmem-rss:1588240kB

A questão é: mesmo tendo uma quantidade de memória livre que fica
sempre entre 3 e 4 GB (livre, o resto é cache + usada), como isso pode
estar acontecendo?


Tiago J. Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Database is in recovery mode

[Tiago José Adami]

Boa tarde a todos.

Tenho um servidor na Amazon com PostgreSQL 9.4.9 64-bit instalado, lá
roda uma versão do Fedora modificada.

Há 16 GB de memória RAM.

max_connections=300
shared_buffers=2GB
work_mem=4MB

De uns tempos para cá, após configurar o backup com arquivamento de
logs está ocorrendo este erro sem muita razão aparente. Sempre ocorre
depois de algum SQL SELECT (não necessariamente o mesmo e dificilmente
usando as mesmas tabelas, já verifiquei isso).

(...)
WARNING,57P02,"terminating connection because of crash of another
server process","The postmaster has commanded this server process to
roll back the current transaction and exit, because another server
process exited abnormally and possibly corrupted shared memory.","In a
moment you should be able to reconnect to the database and repeat your
command."
(...)

A aplicação recebe uma mensagem "Database is in recovery mode". Dura 2
ou 3 segundos e volta ao normal.

Nas minhas pesquisas e até onde vai meu conhecimento isto ocorre com
problemas de hardware, em especial, memórias (lembro-me do tempo do
PostgreSQL 7.4 rodando em servidores com pentes de memória de
velocidade e latências diferentes).

Mas levando em consideração que o servidor está na Amazon... o que
mais poderia estar causando este erro? Algum palpite?


TIAGO J. ADAMI
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tuning?

[Tiago José Adami]

Em 12 de março de 2017 17:40, Pablo Sánchez  escreveu:
> Estou quase pensando em processar o CSV e criar CSV's por separado para
> fazer o copy mesmo.
>
> É um modelo de enderecos basicamente, com apenas umas 8 tabelas, onde um
> endereco/locus pode ser pai de outro. Ex: Brasil é pai de DF que é pai de
> Brasília, que é pai de asa sul, que é pai de SQS 116 que é pai de bloco G,
> por exemplo. Entao a linha tem que ser decomposta, buscar o pai no banco se
> já existe (mas eu cacheio pelo hash do objeto que foi gerado no PHP para não
> ficar indo no banco o tempo todo), e aí tem tipos e etc que também são
> cacheados. Ou seja, nada de outro planeta.
>
> Só que está degradando, e não é no PHP, pois é save que automaticamente o
> arquivo todo é processado em questão de minutos, e o consumo de memória mal
> chega a 500MB.
>
> Agora estou em 300.000 registros já, e a velocidade está em 20 linhas do CSV
> por, mas no comeco, no primeiro minuto, ele processa facilmente 2000 linhas.
> Enfim... Tá foda. :-D

Pablo, no início você escreveu sobre o problema: "que não tem relacão
com o código, mas sim o Postgres".

Ainda não ficou claro onde está o problema. Parece que você não está
fazendo uma importação direto no banco de dados, haja vista que "o
arquivo todo é processado em questão de minutos".

Quais as suas evidências para ter certeza que o problema é no Postgres?

Você chegou a configurar os logs do PostgreSQL para gravar todos os
comandos SQL e o tempo de execução de cada um?

Os comandos SQL são enviados para o banco de dados com que frequência?

Você pouco detalhou o procedimento, mas pelo o que eu estou imaginando
você importou o arquivo todo para uma tabela na sua forma original (um
registro por linha) e depois passou a ler e processar todos os
registros desta tabela (ou do cache do PHP) gravando em outras
tabelas, é isso?

Especifique exatamente o(s) ponto(s) em que o Postgres está demorando
e detalhe melhor o seu processo para podermos ajudá-lo.

Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] not null if

[Tiago José Adami]

Em 19 de janeiro de 2017 19:42, Leandro Guimarães Faria Corcete DUTRA
 escreveu:
> Le jeu. 19 janv. 2017 à 18:45, Alexsandro Haag  a
>
> Sim, esse era meu ponto.  Não entendi, Alexsandro, o que o colega não havia
> entendido.  Mas tudo bem, toquemos o barco…

Eu me expressei mal e expliquei pouco, imaginei outras possíveis
regras de validação que poderiam surgir com o modelo inalterado, mas
faltou a consciência imediata de que para normalizar é preciso alterar
o modelo.

Agora com mais tempo, revendo a questão e com o exemplo do colega
Alexsandro, ficou mais claro ainda. Faltou-me a capacidade de imaginar
um modelo de ER sem saber para quê servem os atributos.

Como disse o Dutra, toquemos o barco, e esqueçamos o ocorrido.

Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] not null if

[Tiago José Adami]

Em 19 de janeiro de 2017 17:26, Guimarães Faria Corcete DUTRA, Leandro
<l...@dutras.org> escreveu:
> 2017-01-19 16:07 GMT-02:00 Tiago José Adami <adam...@gmail.com>:
>>
>> Apesar do OP ter satisfeito sua necessidade, vou insistir nesta
>> questão. Não consegui visualizar como 'obrigar' através de uma tabela
>> complementar o valor em um atributo ser not null
>
> Talvez não tenhamos sido suficientemente claros.  A idéia não é criar
> uma tabela complementar, mas normalizar; em outros termos, pegar uma
> situação em que (aparementemente) há mais de uma entidade ‘misturada’
> (representada) por uma única relação, e transformá-la em duas (ou
> mais) relações, eliminando a possibilidade de anomalias de
> atualização.

Aqui foram apenas exemplos do que poderia ser feito, entendi o que o
Alexsandro quis expor.

> A tua pergunta dá a entender que você ainda não entendeu bem o que são
> as formas normais e a normalização?  Ou foi só mesmo nossas
> explicações sobre este caso que não foram claras?

Acredito não ser um problema de entendimento das formas normais, a sua
primeira resposta ao OP deu a entender que apenas com a normalização o
problema descrito seria resolvido sem a necessidade de implementar
regras adicionais. Agora está claro. Agradeço pela atenção.


TIAGO J. ADAMI
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] not null if

[Tiago José Adami]

 2017-01-19 14:50 GMT-02:00 Alexsandro Haag <alexsandro.h...@gmail.com>:
> Em 19/01/2017 13:27, Tiago José Adami escreveu:
>>
>> Fiquei em dúvida: como seria possível resolver este problema com
>> normalização? Em todas as vezes que me deparei com este tipo de
>> situação resolvi com restrições. Poderia dar um exemplo - mesmo que
>> simplório - para compartilhar conosco? Seria de muito valor!
>
> Olá Tiago, creio que separando esta informação em uma tabela complementar,
> que seria alimentada de acordo com a regra de negócio citada.

Olá, Alexsandro!

Apesar do OP ter satisfeito sua necessidade, vou insistir nesta
questão. Não consegui visualizar como 'obrigar' através de uma tabela
complementar o valor em um atributo ser not null (como no exemplo do
OP) caso o valor de outro atributo (ou conjunto e atributos) seja true
(ou qualquer outro valor).

Entendo que é possível criar uma relação de dependência, como por
exemplo, um registro em uma tabela 'filha' deve existir somente se
outro registro existir em uma tabela 'pai', mesmo assim, o banco de
dados não pode obrigar através de uma forma normal que o registro
exista na tabela 'filha' e na tabela 'pai' ao mesmo tempo.

Quero dizer: o registro pode existir na tabela 'pai' mas a tabela
'filha' pode ter 0 registros e sem o uso de outros meios como triggers
ou validações de regras de negócio em funções de banco ou nas
aplicações não é possível validar isso somente por relacionamentos, o
que não permitiria fazer a restrição do OP.

Você consegue dar um exemplo de como resolver a questão do OP no banco
de dados usando formas normais?

Ou você quis dizer que usando formas normais seria necessário aplicar
uma regra de negócio escrita em função de banco ou em aplicação?


Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] not null if

[Tiago José Adami]

Em 19 de janeiro de 2017 13:15, Guimarães Faria Corcete DUTRA, Leandro
 escreveu:
> 2017-01-19 10:55 GMT-02:00 Rafael Sousa :
>> é possivel colocar um not null apenas se outro campo for por exemplo true ?
>
> Sim, por exemplo com gatilhos, mas não seria um erro de normalização?
> Não seria ideal normalizar?

Fiquei em dúvida: como seria possível resolver este problema com
normalização? Em todas as vezes que me deparei com este tipo de
situação resolvi com restrições. Poderia dar um exemplo - mesmo que
simplório - para compartilhar conosco? Seria de muito valor!

Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] not null if

[Tiago José Adami]

Em 19 de janeiro de 2017 10:55, Rafael Sousa  escreveu:
>
> é possivel colocar um not null apenas se outro campo for por exemplo true ?

É possível criando um check constraint:

postgres=# create database checks;
CREATE DATABASE

postgres=# \c checks;
Você está conectado agora ao banco de dados "checks" como usuário "postgres".

checks=# create table public.teste_check(att1a boolean not null
default false, att2b integer);
CREATE TABLE

## Criação da Check Constraint
checks=# alter table public.teste_check add constraint ck_teste_2b
check ( case when att1a is true then att2b is not null end  );
ALTER TABLE

## Registro válido
checks=# insert into public.teste_check(att1a, att2b) values(false,null);
INSERT 0 1

## Registro inválido, já que attr1a é TRUE, attr2b não pode ser null
checks=# insert into public.teste_check(att1a, att2b) values(true,null);
ERROR:  new row for relation "teste_check" violates check constraint
"ck_teste_2b"
DETALHE:  Failing row contains (t, null).



Adami
___
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 compilando fontes Postgresql

[Tiago José Adami]

> Pergunto-me qual a validade de experimentar questoes de desempenho
> numa versao tao obsoleta, sendo que quase todas as versoes do
> PostgreSQL trazem bons avanços.  Creio que seria mais relevante
> aplicar isso aa v. 10.

Resposta off-topic já que o OP conseguiu resolver seu problema: no
meio acadêmico isso é comum se o mestrando ou doutorando está
reproduzindo os mesmos passos de um trabalho (ou artigo) anterior.
Depende muito do que o orientador define - e deseja.

Entretanto: concordo que o OP pode incrementar muito seu trabalho
aplicando estes experimentos em uma versão mais atual. Seria a cereja
do bolo ;)

Adami
___
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 Pool Glassfish x Max_Connections PostgreSQL

[Tiago José Adami]

Em 22 de dezembro de 2016 12:23, Júlio César Martini
 escreveu:
>
> Caros,
>
> Duas perguntinhas:
>
> 1. Eu utilizo o servidor de aplicação Glassfish para a minha aplicação e lá 
> defino um pool de conexão de 200. No meu PostgreSQL não preciso deixar no 
> max_conections o valor de 200, isso pode ser menor. Estou certo disso?
> Como que consigo mensurar quanto seria o meu max_connections? Atualmente hoje 
> minha app tem em torno de 170 usuários simultâneos acessando e é uma app web.

Você precisará de um número de max_connections no PostgreSQL igual ou
superior ao número máximo e conexões no pool do Glassfish. Cada slot
do pool da aplicação refere-se a uma possível conexão ativa ao banco
de dados, portanto se você deixar um limite menor em algum momento o
seu pool de conexões irá falhar ao criar uma nova conexão.

> 2. Se já uso um pool de conexão no Glassfish eu teria algum ganho usando o 
> pgBouncer?

Se você não estiver em um ambiente com failover gerenciado pelo
pgBouncer e não existem outras aplicações conectando ao banco, não
vejo motivos para usar o pgBouncer.

> PS: Pergunto isso pois hoje estou com um LOAD AVERAGE alto em minha máquina 
> do PostgreSQL. Máquina 4 core com 4GB de memória. O load pode estar ocorrendo 
> por conta dessas conexões. Os checkpoints ocorrem de 5
> em 5 min quando dão timeout.

Já identificou o motivo do LOAD AVERAGE alto? O fato de criar as
conexões e mantê-las ativas não é motivo para aumentar o uso de CPU.

Se sua aplicação está bem escrita (conecta, executa, commit/rollback,
desconecta), você pode tentar reduzir o número de conexões do pool do
Glassfish (e do PostgreSQL também) para reduzir o uso de memória
compartilhada (shared_memory). Entretanto, a utilização de CPU está
ligada diretamente a algum procedimento ou consulta mais complexa em
execução, ou se for uma consulta menos complexa, a quantidade de
ocorrências sequenciais (em outras palavras, executada muitas vezes)
também pode impactar no alto uso de CPU.

Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidao em consulta usando Between com datas iguais

[Tiago José Adami]

Em 15 de dezembro de 2016 09:26, Cleiton Luiz Domazak
 escreveu:
>> Rodou um VACUUM ANALYZE sobre a tabela após criar o índice? Qual a
>> definição (comando) que você usou para criar o índice?
>
> Foi a primeira coisa a ser feita, fiz VACUUM, VACUUM FULL, ANALYZE, REINDEX, 
> o pacote completo .
>
> O indice foi criado apenas em cima do campo data, sem nenhum tipo de 
> formatação ou filtro.

Ok. Isto deveria ter causando algum efeito.

>> > Fiz o restore do dump gerado pelo cliente, e o mesmo problema ocorre no 
>> > meu ambiente de testes. E ocorre em situações um pouco aleatórias.
>> >
>> > Essas são as datas que eu usei e se funcionou ou não. Muito esquisito.
>> >
>> > AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-10-01' OK
>> > AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-11-01' OK
>> > AND DR.DTINSERT>='2016-09-30' AND DR.DTINSERT<='2016-11-01' OK
>> > AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-11-30' OK
>> > AND DR.DTINSERT>='2016-10-30' AND DR.DTINSERT<='2016-11-30' OK
>> > AND DR.DTINSERT>='2016-10-30' AND DR.DTINSERT<='2016-11-01' NOK
>>
>> Qual a quantidade de registros total na tabela e a média mensal?
>
> Se você observar, se aumentar o range de data, a query fica rápida.
>>
>> Primeiro execute um VACUUM ANALYZE sobre a tabela como mencionei antes
>> e depois roda um EXPLAIN para vermos o que o plano de acesso está
>> fazendo para pelo menos uma consulta que ficou OK e para a NOK.
>
> Consegui finalmente rodar o EXPLAIN ANALYZE, e o plano realmente muda, agora 
> vou ver o que mudou e pq.

Desculpe, por um momento esqueci que o EXPLAIN não concluía. De acordo
com as suas informações, se a tabela não possui nenhuma peculiaridade,
há grandes chances de ser algum bug no PostgreSQL.

Antes de analisar o resultado do EXPLAIN, que tal tentar o seguinte:

1) Alterar o predicado da consulta para AND DR.DTINSERT BETWEEN
'2016-10-30' AND '2016-11-01'. Por gentileza informe se houve algum
resultado positivo ou negativo.

2) Instalar mesma versão 9.4.9 em uma outra máquina (talvez uma
máquina virtual?) com SO compatível ao seu ambiente de produção
(Windows ou Linux ou Unix) e importar o dump (pode ser apenas a tabela
em questão) para tentar reproduzir o erro;

3) Se o erro persistir, atualize o PostgreSQL para a versão 9.4.10 e
refaça o teste;

4) Se o erro persistir, instale então a versão 9.5.5 e depois a versão
9.6.1, importe novamente dump e refaça o teste para as duas versões;

Em qualquer momento, se o problema não ocorrer mais, saberemos que já
existe uma versão já com esta anomalia corrigida - então sugiro
proceder com a atualização.

Caso nenhuma das alternativas apresente uma solução é muito importante
coletar o máximo de informações, descrever todas as etapas já
realizadas nos testes e submeter o erro para a lista oficial de bugs
[1] (em inglês, claro) seguindo as recomendações [2].

[1] mailto:pgsql-b...@postgresql.org
[2] https://www.postgresql.org/docs/9.4/static/bug-reporting.html

Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidao em consulta usando Between com datas iguais

[Tiago José Adami]

Em 14 de dezembro de 2016 16:43, Cleiton Luiz Domazak
 escreveu:
> Nem index tinha, criei e ele não é utilizado.

Rodou um VACUUM ANALYZE sobre a tabela após criar o índice? Qual a
definição (comando) que você usou para criar o índice?

>
> Fiz o restore do dump gerado pelo cliente, e o mesmo problema ocorre no meu 
> ambiente de testes. E ocorre em situações um pouco aleatórias.
>
> Essas são as datas que eu usei e se funcionou ou não. Muito esquisito.
>
> AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-10-01' OK
> AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-11-01' OK
> AND DR.DTINSERT>='2016-09-30' AND DR.DTINSERT<='2016-11-01' OK
> AND DR.DTINSERT>='2016-08-30' AND DR.DTINSERT<='2016-11-30' OK
> AND DR.DTINSERT>='2016-10-30' AND DR.DTINSERT<='2016-11-30' OK
> AND DR.DTINSERT>='2016-10-30' AND DR.DTINSERT<='2016-11-01' NOK

Qual a quantidade de registros total na tabela e a média mensal?

Primeiro execute um VACUUM ANALYZE sobre a tabela como mencionei antes
e depois roda um EXPLAIN para vermos o que o plano de acesso está
fazendo para pelo menos uma consulta que ficou OK e para a NOK.

Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidao em consulta usando Between com datas iguais

[Tiago José Adami]

Em 12 de dezembro de 2016 11:45, Cleiton Luiz Domazak
 escreveu:
> (corte)
> Alguém já passou por essa situação?

Eu já: com o PostgreSQL 9.4 (não lembro se era 9.4.2 ou 9.4.3). Nas
últimas releases, por exemplo a 9.4.8 que uso no ambiente de testes
(com mesmo SO), o problema não ocorre.

No meu caso havia uma tabela PUBLIC.RESERVA com um atributo chamado
"DATA" tipo DATE.

Como o servidor (hardware) é fraquinho eu me antecipei e criei vários
índices parciais por ano contendo a cláusula "WHERE DATA BETWEEN
'-01-01' AND '-12-31'" (substituindo  pelos anos de 2014
até 2020). A cláusula between do ano era usada em todas as consultas
envolvendo o atributo DATA.

Adicionalmente a estes índices anuais ainda existia um índice composto
com o atributo DATA, sendo ele o primeiro da lista de atributos do
índice.

Sofri um tempão para descobrir o problema. Como é utilizado um
servidor Debian e o PostgreSQL dos repositórios oficiais a atualização
dos binários demorou um pouco para sair, então tive que encontrar a
solução "na mão", que foi excluir os índices parciais deixando apenas
um índice "normal" utilizando o atributo "DATA".

Sendo assim:

1) Certifique-se de estar utilizando a última release da versão 9.4;

2) Verifique se existem índices parciais sobre este atributo de data;

3) Teste em outro ambiente com o mesmo SO se o problema ocorre após
importar um arquivo de DUMP;

3.1) Caso no ambiente de testes funcione, você pode cogitar a
possibilidade de fazer um DUMP completo, apagar o banco de dados,
criar um novo e reimportar o DUMP no mesmo servidor. Se houver algo
corrompido isto deve resolver;


Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Aplicação desktop com banco de dados hospedado em VPS.

[Tiago José Adami]

Em 27 de setembro de 2016 11:36, Matheus Saraiva
 escreveu:
> Queria saber se alguém já teve um cenário parecido com esse e qual foi a
> experiência.
> Tenho um sistema local desktop e preciso compartilhar esses dados com o site
> da empresa. Minha ideia inicial é contratar um VPS e migrar esse banco para
> ele, no mesmo VPS ficará o servidor web com o site. Na aplicação desktop
> será configurada a conexão para apontar para o banco no VPS.
> A quantidade de acessos simultâneos ao site será pequeno geralmente
> limitando-se aos clientes da empresa, talvez uma média de 10 simultâneos ou
> nem isso. Até mesmo o acesso pela aplicação local não é constante,
> geralmente só da hora de fazer uma venda/locação máximo de 30
> vendas/locações por dia.
> Em fim, trata-se de uma micro-empresa com necessidades modestas, mas tenho
> preocupação com relação ao tempo de resposta entre a aplicação desktop e o
> banco no VPS. Como a operação de venda/locação não exige pressa, acredito
> que até 5 segundos (para ter os dados na tela) seria aceitável.
> A aplicação desktop não usa frameworks orm, e faz uso de views para a
> maioria consultas e usa funções plpgsql para a maioria das inserções,
> deleções e updates.
> Minha preocupação não é com o site pois para ele será uma topologia trivial
> de hospedagem, minha preocupação é a aplicação desktop.

O aplicativo Desktop é MS Windows? Existe a possibilidade de colocar
tudo em um VPS, até o aplicativo Desktop, rodando via Terminal
Service? O tráfego das "telas" via Terminal Server é mais eficiente
que trafegar dados direto "no" banco.

Uma das empresas que trabalhei operam desta forma com vários usuários
simultâneos e com sistemas ERP complexos quando o cliente não quer
hospedar o próprio sistema por falta de hardware, e a conexão "na
ponta" do cliente geralmente é ADSL 10 Megabits. Funciona muito bem
(enquanto o cliente tem acesso à Internet).

TIAGO J. ADAMI
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Duvidas com relacionamentos ( Tabela Filha Obrigatória )

[Tiago José Adami]

Em 14 de setembro de 2016 08:29, Gustavo  escreveu:
> tenho 2 tabelas  Pedidos e ItensPedidos
> e claro que temo o relacionamento 1:n  de entre as tabelas Pedidos e 
> ItensPedidos

Ok.


> Gostaria de saber se existe uma maneira da tabela filha( itensPedidos) ser 
> obrigada e ser preenchida utilizando apenas alguma configuração do 
> relacionamento  ?

O que você quer dizer com "apenas alguma configuração do relacionamento" ?


> ps: sei que podemos fazer isso na raça com alguns Selects  para fazer essas 
> verificações

Pode dar algum exemplo?


TIAGO J. ADAMI
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Diversão com restrições

[Tiago José Adami]

Em 8 de setembro de 2016 17:17, Guimarães Faria Corcete DUTRA, Leandro
 escreveu:
> 2016-09-08 17:15 GMT-03:00 Fabrízio de Royes Mello :
>> Um índice parcial é criado para agir em uma
>> porção da tabela de acordo com o predicado definido (aka WHERE), então
>> você pode criar um índice regular ou um "unique" que irá respeitar as
>> tuplas envolvidas na porção definida pelo mesmo.
>
> Obrigado!  Mas acho que ainda merece uma explicação ainda mais clara
> para leigos.

Acontece muito em modelos onde há uma entidade, digamos, PESSOA, que
possui vários, digamos, ENDERECO, mas somente 1 ENDERECO pode ser
marcado como principal para cada PESSOA.

Normalmente recorre-se à triggers para fazer essa validação em banco
(eu, troglodita, faria isso), tendo que fazer um SELECT FOR UPDATE
verificando se já existe um principal para permitir a alteração, o que
foi solucionado simplesmente com um índice único parcial.

... nunca pensei nisso, diga-se de passagem.


TIAGO J. ADAMI
___
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 sistema operacional para banco de dados PostgreSQL

[Tiago José Adami]

Em 30 de agosto de 2016 11:11, Guimarães Faria Corcete DUTRA, Leandro
<l...@dutras.org> escreveu:
> 2016-08-30 10:31 GMT-03:00 Tiago José Adami <adam...@gmail.com>:
>> No "muita coisa" eu destacaria compatibilidade com o hardware. Apesar
>> de não ser comum nos dias atuais já presenciei casos em que foi
>> necessário trocar uma distro Linux por outra em razão deste motivo.
>
> Estranho.  Na pior das hipóteses, pega-se o acionador de dispositivo
> (que tem de ser livre, em razão da GNU GPL) da distro ‘que funciona’ e
> transfere-se para a preferida.  Ou tem algo mais complicado que isso?

Havia uma controladora de discos a qual possuía os "drivers" ou
acionadores de dispositivos de código fechado disponível apenas em
pacotes RPM. Mesmo com muito afinco e várias tentativas não foi
possível configurá-lo no Debian (o desempenho era horrível e o
multipath não funcionava), talvez até por incapacidade técnica dos
SysAdmins. A solução - inclusive recomendada pelo fabricante por ser
um SO "homologado" - foi usar RHEL.

TIAGO J. ADAMI
___
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 sistema operacional para banco de dados PostgreSQL

[Tiago José Adami]

Em 30 de agosto de 2016 09:39, Guimarães Faria Corcete DUTRA, Leandro
 escreveu:
>
> Eu recomendaria ou um Debian GNU/Linux, ou um *BSD.  Mas depende de muita 
> coisa.

No "muita coisa" eu destacaria compatibilidade com o hardware. Apesar
de não ser comum nos dias atuais já presenciei casos em que foi
necessário trocar uma distro Linux por outra em razão deste motivo.
Desconheço se os *BSD da vida estão atualizados neste aspecto.

Dada a maturidade das distros Linux atuais eu optaria por *BSD apenas
se houvesse algum motivo muito forte.

TIAGO J. ADAMI
___
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: Chave Primaria Composta

[Tiago José Adami]

2016-08-26 0:30 GMT-03:00 Euler Taveira <eu...@timbira.com.br>:
> On 25-08-2016 14:17, Tiago José Adami wrote:
>>Também há 2 triggers um pouco mais complexos que não permitem
>>horários conflitantes, algo impossível de tratar apenas com FKs.
>>
> Você tentou usar range types [1] e/ou restrições de exclusão [2] (ex. [3])?
>
> [1] https://www.postgresql.org/docs/9.6/static/rangetypes.html
> [2]
> https://www.postgresql.org/docs/9.6/static/sql-createtable.html#SQL-CREATETABLE-EXCLUDE
> [3]
> http://stackoverflow.com/questions/10759531/exclusion-constraint-with-overlapping-timestamp-range#10760028

Inicialmente a implementação dos triggers foi feita ainda quando as
chaves primárias eram compostas e era necessário validar junto as
chaves realmente naturais (em campos fora das PKs) pelo código dos
triggers. Depois de migrar as tabelas para usar chaves naturais
simplesmente ajustei o código no tocante às chaves e tudo funcionou
perfeitamente, portanto não procurei algo para substituir os triggers.

Agora que as tabelas possuem chaves naturais adequadas e o projeto
está quase homologado, vou me planejar para investir um tempo nisso.

TIAGO J. ADAMI
___
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: Chave Primaria Composta

[Tiago José Adami]

Em 25 de agosto de 2016 15:10, Fabiano Machado Dias
 escreveu:

> Quando vc varre uma tabela de itens de uma nota, vc está buscando dados do
> item né? E a programação de entrega desse item? Não está em outra tabela
> ainda? Entende o que quero dizer?

Sim, entendo. Quando você envolve outras entidades certamente é
inevitável consultar outras tabelas. Neste caso provavelmente não
haveria ganho ou perda entre as duas abordagens (chaves compostas
naturais ou artificiais únicas).

>> Apenas "O" índice da chave primária fica maior. Você poderá ter
>> índices auxiliares que terão o mesmo tamanho.
>
> Mesmo exemplo acima. Nota/item/programacao_entrega - vejo o tamanho desses
> índices em um caso real.

Depende de cada caso. Ainda assim, um índice "grande" por tabela não
representa muito espaço adicional.

>> > 3 - Vc tem uma redundância de informações e maior consumo de espaço
>>
>> Isto é fato. Na migração do banco o crescimento foi na ordem de cerca
>> de 20% com os testes que fiz. Contrabalanceando, o desempenho das
>> consultas ficou muito mais rápido.
>
> Não sei o tamanho das bases que trabalha, mas pra mim é um problema em
> vários clientes atualmente (bases na case de alguns teras)

Este caso da UTFPR é um sistema pequeno, o banco de dados não chega a
2 GB hoje. Atendo clientes com bases da ordem de 1 TB ou mais, e lhe
garanto que quanto maior o tamanho, maior o tombo. As inconsistências
geradas pelo uso de chaves artificiais, muito semelhantes aos que
citei no caso do meu sistema, são constantes.

E tem mais: se desde o início o sistema for concebido da forma
correta, qual o problema para o cliente em se planejar?

>> > 4 - A escrita (lembrando de modelos grandes) fica bem maior, supondo que
>> > você precise unir 30 tabelas cada uma com 10 campos na sua chave, pense
>> > no
>> > tamanha da instrução.
>> >
>>
>> A escrita ou a união em um SQL?  Acredito que exista, sim, uma carga
>> adicional na escrita, mas isso é irrelevante em relação aos benefícios
>> obtidos, principalmente no desempenho das consultas.
>
>
> Olha, hoje em dia eu vejo cada vez menos desenvolvedores com conhecimentos
> de SQL, quando eu mostro uma consulta com vários join's vários arrepiam os
> cabelos, mas sim é irrelevante quando se sabe o que está fazendo.

Isso é verdade. Cada vez mais estão ficando preguiçosos e muito
"NoSQL". A resposta que sempre dou quando participo de um projeto
assim: ou o desenvolvedor/programador aprende SQL básico, ou está fora
do projeto. De qualquer forma pode haver alguém para criar as
consultas, a minha empresa mesmo trabalha em projetos prestando
consultoria e apoio aos desenvolvedores neste sentido.
Você tem que escolher entre um sistema bem feito para agradar os
clientes ou agradar os programadores. Eu prefiro a primeira opção :)


>> Sobre "unir 30 tabelas cada uma com 10 campos na sua chave": Para isto
>> existe o NATURAL JOIN. E repito, com o modelo feito com propagação de
>> chaves naturais, pela minha experiência a necessidade de usar tabelas
>> intermediárias diminui muito. Dificilmente uma consulta mais complexa
>> do sistema hoje faz JOIN com mais de 2 tabelas, sendo que antes eram
>> necessárias pelo menos 3 tabelas em JOIN em *todas* as consultas SQL.
>
>
> Não estou sendo contra as chaves naturais, mas acho que vc pode obter o
> melhor sabendo usar os 2 cenários

Sim, entendi. Concordo que muitas vezes há tantas "buchas" já pela
metade que não temos como mudar tudo. Mas a ideia central é começar já
fazendo certo, com chaves compostas naturais.


TIAGO J. ADAMI
___
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: Chave Primaria Composta

[Tiago José Adami]

Em 25 de agosto de 2016 14:42, Guimarães Faria Corcete DUTRA, Leandro
 escreveu:
> E imagino que tanto desempenho quanto carga de máquina e de rede,
> usabilidade e manutenção melhorem muito.

Compreendi teu ponto de vista com a mensagem anterior. Aproveitei para
lhe dar o crédito da minha implementação - considerando tuas
incessantes reafirmações na lista para que usemos chaves naturais. Não
é preciso dizer isso, mas, "Dutra, você sempre esteve certo" :)

Quanto ao desempenho: as consultas SQL ficaram mais simples e mais
rápidas. E manutenção, no modelo novo, ainda não surgiu, mas todo o
projeto ficou mais "legível" e compreensível.

Se alguém tiver interesse em visualizar o projeto antigo (ogro com
chaves artificais) ele está sob domínio público no GitHUB [1]. Ainda
não subi o novo porque estou finalizando localmente e há uma
reformulação de repositórios e projetos da UTFPR em curso.

[1] https://github.com/utfpr-dv/derdi-dv

P.S: antes que me critiquem pela segurança, as senhas e geradores de
senha que estão ali não são mais usados :)


TIAGO J. ADAMI
___
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: Chave Primaria Composta

[Tiago José Adami]

Em 25 de agosto de 2016 14:46, Fabiano Machado Dias
 escreveu:
> Sim, eu entendo a "vantagem" de evitar join e você "ter" o dado já na filha
> ou "neta" da tabela.
>
> Mas assim, no que eu vi, na prática é o seguinte:
>
> 1 - A informação da chave, geralmente não é a que vc quer, então o join vai
> acontecer igual

Discordo. Se suas chaves naturais estão bem definidas, na grande
maioria das vezes é suficiente. Por exemplo: a consulta mais
recorrente sobre a tabela RESERVA é listar todas as reservas do campus
'DV' e do usuário logado no sistema pelo campo matricula_usuario. Não
preciso de JOIN para fazer isso com o "modelo natural".

Esta declaração só é verdadeira no caso de relatórios que busquem mais
informações, mas neste caso você pode eliminar o JOIN com tabelas
intermediárias, tornando o modelo com chaves naturais ainda mais
eficiente.

> 2 - Os índices ficam bem maiores

Apenas "O" índice da chave primária fica maior. Você poderá ter
índices auxiliares que terão o mesmo tamanho.

> 3 - Vc tem uma redundância de informações e maior consumo de espaço

Isto é fato. Na migração do banco o crescimento foi na ordem de cerca
de 20% com os testes que fiz. Contrabalanceando, o desempenho das
consultas ficou muito mais rápido.

> 4 - A escrita (lembrando de modelos grandes) fica bem maior, supondo que
> você precise unir 30 tabelas cada uma com 10 campos na sua chave, pense no
> tamanha da instrução.
>

A escrita ou a união em um SQL?  Acredito que exista, sim, uma carga
adicional na escrita, mas isso é irrelevante em relação aos benefícios
obtidos, principalmente no desempenho das consultas.

Sobre "unir 30 tabelas cada uma com 10 campos na sua chave": Para isto
existe o NATURAL JOIN. E repito, com o modelo feito com propagação de
chaves naturais, pela minha experiência a necessidade de usar tabelas
intermediárias diminui muito. Dificilmente uma consulta mais complexa
do sistema hoje faz JOIN com mais de 2 tabelas, sendo que antes eram
necessárias pelo menos 3 tabelas em JOIN em *todas* as consultas SQL.



TIAGO J. ADAMI
___
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: Chave Primaria Composta

[Tiago José Adami]

Em 25 de agosto de 2016 14:29, Fabiano Machado Dias
 escreveu:
> Legal, você poderia usar UK's e ainda assim manter a suas chaves
> artificiais, muitas vezes a preocupação com a chave primária faz com que as
> pessoas esqueçam que podemos ter N UK's para manter a integridade nos
> trilhos e no banco!
>
> Hoje tenho diversos projetos onde o uso de ORM é constante, para conviver
> com ele faço isso, o fato é que tabela sem chave natural é o inferno de
> qualquer modelo.

Mas o uso de UK's (você se refere a UNIQUE INDEXES, certo?) não
garante a integridade lógica entre as tabelas, apenas entre os
registros de uma só tabela. Por exemplo, eu poderia ter a tabela de
reservas como antes:

CREATE TABLE reserva (
/* PK artificial, única */
id_reserva SERIAL NOT NULL,

/* FK tabela ITEM_RESERVA */
id_item_reserva INTEGER NOT NULL,

/* FK tabela PESSOA */
id_pessoa INTEGER NOT NULL,

(...)
)

Uma das regras do sistema é que apenas servidores do próprio campus
possam fazer reservas dos itens do seu campus.

Nesse modelo com chaves artificiais acima, mesmo que haja um índice
único não impede de fazer uma reserva de um item do campus A para uma
pessoa do campus B. Só se você implementar um TRIGGER que valide isso
e retorne uma exceção, mas aí já começa a complicar demais o modelo.

Outra vantagem das chaves naturais é saber pela tabela "filha" quem
são os "pais". Neste exemplo com chaves artificiais, eu precisava
fazer JOIN com mais 3 tabelas para saber qual o campus.

TIAGO J. ADAMI
___
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: Chave Primaria Composta

[Tiago José Adami]

Em 25 de agosto de 2016 14:17, Tiago José Adami <adam...@gmail.com> escreveu:
> CREATE TABLE reserva_item_autorizacao (

Corrigindo os comentários

Tabela RESERVA_ITEM só possui 2 FKs:
- codigo_patrimonio é FK da tabela ITEM_RESERVA;
- demais campos são FK da tabela RESERVA

Tabela RESERVA_ITEM_AUTORIZACAO só possui 2 FKs:
- matricula_autorizacao é FK da tabela PESSOA;
- demais campos são FK da tabela RESERVA_ITEM

TIAGO J. ADAMI
___
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: Chave Primaria Composta

[Tiago José Adami]

Em 25 de agosto de 2016 13:44, Guimarães Faria Corcete DUTRA, Leandro
 escreveu:
> Mas de fato há situações em que uma chave pode chegar a cobrir todos
> os atributos (naturais) de uma relação (não confundir com
> relacionamento).

E eu avalizo totalmente esta declaração. E ainda quero citar um
exemplo do porquê chaves naturais compostas DEVEM ser utilizadas
sempre que possível.

Vou citar um exemplo de um software de reservas desenvolvido para a
UTFPR campus DV e que está em uso agora em 2 campus. Inicialmente toda
a camada de acesso a dados utilizava Hibernate (JSF + Hibernate +C3P0)
com PostgreSQL 9.4 usando os famigerados "IDs" e chaves artificiais
autoincremento para tudo, para facilitar a integração com Hibernate.

Enquanto o software esteve rodando para 1 campus apenas (Dois
Vizinhos), não houveram muitos problemas.

Para encurtar o papo, quando começou a importação de dados de um tal
aSc TimeTables que define reservas de salas e horários por disciplinas
e turmas, começou a dor de cabeça. Os usuários importavam 2x o mesmo
XML e os "ID's" por não serem chaves naturais permitiam a duplicação
dos dados.

Pior ficou quando fiz testes para inclusão de um outro campus...

Um item que estava cadastrado para o campus DV (uma sala de aula, por
exemplo) poderia ser reservado em outro campus (erro de lógica). As
FK's e PK's não garantiam integridade lógica, apenas integridade
referencial (filho sem pai). A ideia central do sistema que era ficar
hospedado em um servidor apenas caiu por terra, foi necessário então
solicitar ao outro campus que hospedasse uma nova instância do
aplicativo.

Comecei a trabalhar no projeto com afinco. Refiz todo o modelo usando
chaves naturais e abandonei o Hibernate pelo sql2o. Deu um pouco mais
de trabalho no começo, mas depois tudo fluiu com uma naturalidade
fantástica. Ainda estou testando a nova versão e logo farei a migração
dos dados.

Como exemplo à declaração do Dutra, a tabela RESERVA_ITEM_AUTORIZACAO
possui 7 campos em sua chave primária, todos naturais que são todos os
campos da tabela. Ou seja, é uma tabela onde todos os campos são parte
da chave primária, sendo uma tabela "clássica" de relacionamento N*N.

Finalizando minha "história", com exceção de um índice único e 2
TRIGGERs para tratar horários conflitantes, toda a integridade lógica
ficou GARANTIDA apenas pelo uso das FK's e PK's com atributos
naturais, mesmo que com vários campos. E o número de FK's foi reduzido
para 1 terço do que havia antes, pois a propagação das chaves
compostas garante a integridade com a tabela "pai" de todos os níveis
superiores.

Abaixo segue o modelo atual no qual estou trabalhando (omiti demais
campos que não são chave):

CREATE TABLE pessoa(
/* PK - chave natural - código de cada servidor público */
matriculaVARCHAR(20) NOT NULL,
(...)
);

CREATE TABLE instituicao (
/* PK - chave natural - código do MEC */
sigla VARCHAR(20) NOT NULL,
(...)
);


CREATE TABLE campus (
/* PK e FK tabela INSTITUICAO */
sigla_instituicao VARCHAR(20) NOT NULL,

/* PK - chave natural - código do MEC */
sigla_campus VARCHAR(20) NOT NULL,
(...)
);

/* "Cadastro" de itens */
CREATE TABLE item_reserva (
/* PK e FK tabela CAMPUS */
sigla_instituicao VARCHAR(20) NOT NULL,

/* PK e FK tabela CAMPUS */
sigla_campus VARCHAR(20) NOT NULL,

/* PK - chave natural - código de patrimonio interno do campus */
codigo_patrimonio VARCHAR(20) NOT NULL,
(...)
);

CREATE TABLE reserva (
/* PK e FK tabela ITEM_RESERVA */
sigla_instituicao VARCHAR(20) NOT NULL,
/* PK e FK tabela ITEM_RESERVA */
sigla_campus VARCHAR(20) NOT NULL,
/* PK - chave natural */
data_reserva_inicioTIMESTAMP NOT NULL,
/* PK - chave natural */
data_reserva_fimTIMESTAMP NOT NULL,
/* PK e FK tabela PESSOA */
matricula_usuarioVARCHAR(20) NOT NULL,
(...)
);


/* Cada reserva pode incluir mais de um item, portanto aqui fica
   separado da tabela reserva

   Há aqui um indice único entre os campos
sigla_instituicao,
sigla_campus,
data_reserva_inicio,
codigo_patrimonio

   Também há 2 triggers um pouco mais complexos que não permitem
   horários conflitantes, algo impossível de tratar apenas com FKs.

   Motivo: um mesmo item não pode ser reservado 2x na mesma
   data e hora, ou enquanto uma reserva ainda está ativa */
CREATE TABLE reserva_item (
/* PK e FK tabela ITEM_RESERVA */
sigla_instituicao VARCHAR(20) NOT NULL,
/* PK e FK tabela ITEM_RESERVA */
sigla_campus VARCHAR(20) NOT NULL,
/* PK - chave natural */
data_reserva_inicioTIMESTAMP NOT NULL,
/* PK - chave natural */
data_reserva_fimTIMESTAMP NOT NULL,
/* PK e FK tabela PESSOA */
matricula_usuarioVARCHAR(20) NOT NULL,
/* PK e FK tabela ITEM_RESERVA */
codigo_patrimonio VARCHAR(20) NOT NULL,
(...)
);

/* 

Re: [pgbr-geral] Chave Primaria Composta

[Tiago José Adami]

Em 25 de agosto de 2016 11:33, Gustavo  escreveu:
>
>  (lembro que eram quase 4 mil tabelas), ouch !
>
> o meu só tem 1.000 tabelas...   será que terei problemas com performance 

O número de tabelas não é preponderante no impacto de desempenho.
Alguns softwares/sistemas muito bem escritos conseguem ter uma
quantidade imensa de tabelas mas aplicando no mínimo a 3FN, com cada
tabela/entidade servindo a um propósito específico com poucas
colunas/atributos - muito bem indexadas, claro.

TIAGO J. ADAMI
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Começando no recurso de usuários

[Tiago José Adami]

Em 13 de agosto de 2016 18:42, Tiago José Adami <adam...@gmail.com> escreveu:
> (...) Isso precisará ser
> modificado para que o programa abra e feche diversas transações (...)
>

Eu costumo me referir erroneamente às conexões como transações. Neste
caso, leia-se "conexões" e não "transações".

Mea culpa.

TIAGO J. ADAMI
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Começando no recurso de usuários

[Tiago José Adami]

Em 13 de agosto de 2016 11:31, Matheus Saraiva
<matheus.sara...@gmail.com> escreveu:
> Em 12-08-2016 20:50, Tiago José Adami escreveu:
>>
>> Abro um parênteses: Conexões diretas ao banco via VPN? Não seria
>> melhor alguma forma de colocar a interface do lado do servidor para
>> evitar expor o banco de dados? O desempenho disso não vai ser muito
>> bom, já vi várias tentativas frustradas de conexões remotas com VPN,
>> em especial porque há um overhead significativo para compressão e
>> criptografia dos dados.
>
> Eu quis expor de forma direta, não entrei em detalhes pois não é o foco da
> pergunta, mas sim, a ideia é ter uma camada interfaceando o banco na web.
> Também já levei em consideração o desempenho, por isso decidi mandar o banco
> pra nuvem. Não tenho como mandar a aplicação pra nuvem por se tratar de um
> front-end desktop.

Exatamente por isso que eu me fiz este comentário. Se o front-end é
Desktop há a possibilidade de usar um servidor de aplicações remotas,
como Windows Terminal Server ou Citrix Metaframe. O custo efetivo de
se usar um servidor de aplicações remotas é muito menor, pois não
haverá necessidade de investir em banda larga muito alta (de ambos os
lados cliente/servidor) e o gerenciamento é mais fácil. Presto suporte
para diversas empresas que trabalham desta forma com ERP "for Windows"
sem maiores problemas.

> Pois é, eu faço uso pool via aplicação, mas já li por ai (e acho que tem um
> pouco de lógica) que controle de pool na aplicação em sistemas desktop é
> desnecessário, visto que aplicações desktop geralmente são cliente/servidor
> e necessitam de apenas uma conexão por tarefa, salvo casos de multi-thread.

Sim, concordo. Quando me referi em controlar o pool de conexões na
aplicação foi pensando em um middle-tier ou web container.

> Já para aplicações WEB acho que realmente seria um problema.
> Eu sempre utilizei o próprio driver para fazer pooling, nunca usei
> utilitários de pool "externos" fazendo interface com o banco.
>
> Minha ideia atualmente é colocar o banco e o webserver em um VPS. E o ERP
> desktop instalado localmente acessando o banco na nuvem. Nesse caso acho que
> um pool independente interfaceando os acesos do site e do ERP é a melhor
> opção.

Se eu entendi corretamente, neste caso o pgBouncer vai te ajudar
muito. Porém, geralmente os aplicativos Desktop tem o péssimo hábito
de criar uma conexão ao banco de dados quando o programa é iniciado e
só fecham a conexão quando o programa é fechado. Isso precisará ser
modificado para que o programa abra e feche diversas transações (se já
não estiver funcionando corretamente). Já nos aplicativos Web,
"geralmente" já fazem certo.

TIAGO J. ADAMI
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ajuda com Select

[Tiago José Adami]

Em 6 de agosto de 2016 16:13, Tiago José Adami <adam...@gmail.com> escreveu:
> Em 5 de agosto de 2016 16:51, Edson F. Lidorio <ed...@openmailbox.org> 
> escreveu:
>> Opa!
>> Quase isso, Preciso considerar:
>>
>> - todos os produtos
>
> Não ficou claro, mas acredito que você deseje incluir todos os
> produtos da tabela produto mesmo que não haja registros na tabela
> historico_vendas, correto? Isto pode ser resolvido com um LEFT/RIGHT
> OUTER JOIN. Veja o exemplo do SQL abaixo.
>
>> - e também fazer a média por 1 ano dos produtos que tem menos de 1 ano
>
> Você especificou no post original que deseja uma média de 1 ano. O SQL
> abaixo irá trazer *todos* os produtos, de 1 ano atrás até a data
> atual. A média será pelo período inteiro (1 ano = 12 meses = 365 ou
> 366 dias se for ano bissexto). Com este código SQL abaixo você terá a
> média do último ano de todos os produtos, independente de quando foram
> cadastrados.
>
>
> SELECT
> pr.id_produto,
> pr.nome_produto,
> AVG(COALESCE(hv.qtde_produto,0)) as qtde_produto_media
> FROM
> produtos pr
> LEFT OUTER JOIN
> historico_vendas hv ON
> pr.id_produto = hv.id_produto
> WHERE
> hv.data_venda >= CURRENT_DATE - INTERVAL '1 YEAR'
> GROUP BY
> pr.id_produto,
> pr.nome_produto

Depois do envio do e-mail que eu me liguei que faltou fazer uma
pergunta: Você deseja a média diária, mensal, semanal ou qual período
dentro do ano? De uma forma grosseira, se você deseja a média mensal
dentro do ano, o SQL seria mais ou menos assim:

SELECT
pr.id_produto,
pr.nome_produto,
SUM(COALESCE(hv.qtde_produto,0))/12 as qtde_produto_media_mensal
FROM
produtos pr

LEFT OUTER JOIN
historico_vendas hv ON
pr.id_produto = hv.id_produto
WHERE
hv.data_venda >= CURRENT_DATE - INTERVAL '1 YEAR'
GROUP BY
pr.id_produto,
pr.nome_produto

TIAGO J. ADAMI
http://www.adamiworks.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ajuda com Select

[Tiago José Adami]

Em 5 de agosto de 2016 16:51, Edson F. Lidorio  escreveu:
> Opa!
> Quase isso, Preciso considerar:
>
> - todos os produtos

Não ficou claro, mas acredito que você deseje incluir todos os
produtos da tabela produto mesmo que não haja registros na tabela
historico_vendas, correto? Isto pode ser resolvido com um LEFT/RIGHT
OUTER JOIN. Veja o exemplo do SQL abaixo.

> - e também fazer a média por 1 ano dos produtos que tem menos de 1 ano

Você especificou no post original que deseja uma média de 1 ano. O SQL
abaixo irá trazer *todos* os produtos, de 1 ano atrás até a data
atual. A média será pelo período inteiro (1 ano = 12 meses = 365 ou
366 dias se for ano bissexto). Com este código SQL abaixo você terá a
média do último ano de todos os produtos, independente de quando foram
cadastrados.


SELECT
pr.id_produto,
pr.nome_produto,
AVG(COALESCE(hv.qtde_produto,0)) as qtde_produto_media
FROM
produtos pr
LEFT OUTER JOIN
historico_vendas hv ON
pr.id_produto = hv.id_produto
WHERE
hv.data_venda >= CURRENT_DATE - INTERVAL '1 YEAR'
GROUP BY
pr.id_produto,
pr.nome_produto





TIAGO J. ADAMI
http://www.adamiworks.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ajuda com Select

[Tiago José Adami]

Em 5 de agosto de 2016 14:22, Edson F. Lidorio  escreveu:
> Boa tarde Pessoal,
>
> Estou precisando de um ajuda para montar o select abaixo:
> Preciso exibir uma média de consumo de produtos gastos nos últimos 12 meses.
> Considerando que só irei informar a data atual no select e que preciso pegar
> todos produtos e fazer a medias de todos produtos gastos nos últimos 12
> meses.
>
> Tabela: histórico_vendas
> data_venda
> id_produto
> qtde_produto
>
> Tabela: produtos
> id_produto
> nome_produto

Veja se isso te ajuda:

SELECT
hv.id_produto,
pr.nome_produto,
AVG(qtde_produto) as qtde_produto_media
FROM
historico_vendas hv
JOIN
produtos pr ON
pr.id_produto = hv.id_produto
WHERE
hv.data_venda >= CURRENT_DATE - INTERVAL '1 YEAR'
GROUP BY
hv.id_produto,
pr.nome_produto


TIAGO J. ADAMI
http://www.adamiworks.com
http://www.clouddba.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Como organizar o BD para uma aplicação SaaS?

[Tiago José Adami]

Em 5 de agosto de 2016 10:49, Angelo A. Frozza (Gmail)
 escreveu:
> Olá,
>
> Gostaria da opinião sobre como está sendo feito na prática a gerência de
> BD no caso de aplicações SaaS.
>
> Vamos a um estudo de caso: imagine uma aplicação (Comércio
> Eletrônico/Controle de estoque etc.), que o cliente contrata através da
> Web e utiliza via SaaS - Software as a Service. O BD é PostgreSQL.
>
> A pergunta é como fazer a distribuição do BD e quais
> vantagens/desvantagens da solução proposta.
>
>
> Algumas opções foram levantadas:
>
> a) Para cada novo cliente, é atribuída uma instância própria do PostgreSQL;
>
> b) Servidor compartilhado, cada cliente tem seu próprio BD;
>
> c) Servidor compartilhado, BD compartilhado, mas cada cliente acessa um
> Schema diferente;
>
> d) Outras opções...

Olá prof. Angelo.

Em 2015 fiz uma pergunta semelhante aqui no grupo e recebi várias
sugestões. Acho interessante partir do que foi discutido nesta thread
[1] antiga.

[1] https://listas.postgresql.org.br/pipermail/pgbr-geral/2015-April/040386.html

TIAGO J. ADAMI
http://www.adamiworks.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Trocar separador de campos de um RECORD

[Tiago José Adami]

Em 20 de julho de 2016 18:24, Heloisa Fernanda
 escreveu:
> Olá Pessoal!
>
> Estou trazendo o resultado de uma consulta em um record, ex:
>
> SELECT
> exame::TEXT
> FROM
> exame;
>
> Retorna algo assim: (ZIKAG,"ZIKA VÍRUS ANTICORPOS IGG","Para descartar
> infecção recente, realizar ensaio de IgM ou soroconversão em IgG no
> intervalo de 3 a 4 semanas.",1)
>
> Mas preciso trocar o separador de campos de vírgula para alguma outra coisa,
> alguém tem ideia de como fazer isso?
>

Olá, Heloisa.

Tente isso:

SELECT
   REPLACE(exame::TEXT, ',', ';') as exame
FROM
   exame;

O primeiro parâmetro da função REPLACE [1] é a entrada, o texto
principal. O segundo é o caractere que você quer substituir e o
terceiro o novo substituto. Neste caso troquei as vírgulas por
ponto-e-vírgula.


[1] https://www.postgresql.org/docs/9.5/static/functions-string.html

TIAGO J. ADAMI
http://www.adamiworks.com
http://www.clouddba.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Serviço do Postgre não levanta [BRT FATAL: não pôde criar nenhum soquete TCP/IP]

[Tiago José Adami]

>> From: "Fabio Luis Rodrigues" 
>> To: "Comunidade PostgreSQL Brasileira" 
>> Sent: Monday, July 4, 2016 8:28:10 AM
>> Subject: [pgbr-geral] Serviço do Postgre não levanta [BRT FATAL: não pôde
>> criar nenhum soquete TCP/IP]
>>
>> Bom dia Pessoal,
>>
>> Meu server de desenvolvimento (Windows) não consegue estartar o serviço do
>> Postgre.
>>
>> "BRT FATAL: não pôde criar nenhum soquete TCP/IP"
>>
>> Alguém sabe como levantar isso?
>
> Em 4 de julho de 2016 16:10, Jeferson Santana 
>  escreveu:
> Olá Fabio
>
> Verifique se outra instância do PostgreSQL utilizando a porta 5432.
>
> Também há outras 2 opções:
>
> 1- Solução Microsoft (desliga e liga)
>
> 2- Migrar para Linux :)

Como o Jeferson já citou, você terá que fazer o "dever de casa" de
quem usa Windows:

3- Verifique se há algum software antivírus com firewall bloqueando a
porta 5432 (ou a porta configurada para a instância do PostgreSQL). No
meu caso já tive problemas com o McAfee e Windows 10. Se possível pare
todos os serviços de antivírus/firewall e tente iniciar o serviço;

4- Abre o prompt de comando (cmd.exe) com elevação (ou como
administrador) e execute o comando abaixo para verificar se há algum
registro enquanto o seu serviço do PostgreSQL estiver parado. Troque
5432 pela porta configurada para a instância caso você tenha alterado
a porta padrão no arquivo postgresql.conf:

netstat -ab | findstr "5432"

Se retornar alguma coisa, você terá que: a) mudar a porta do serviço
do PostgreSQL no arquivo postgresql.conf ou então b) descobrir qual é
o aplicativo que está usando esta porta e "matá-lo";

5- Verifique as credenciais do usuário que está configurado para
iniciar o serviço do PostgreSQL. No Windows 10 o usuário deve se
chamar "Serviço de Rede" ou "Net Service". Se você por algum motivo
alterou o nome do usuário, retorne para este usuário de rede (muitos
instaladores customizados alteram o nome do usuário do serviço e isso
dá muita dor de cabeça, nem sei se isso é possível de fazer nas
versões acima da 9.3).

6- Se nada disso ajudar, verifique se você tem pelo menos 1 placa de
rede instalada no computador com o protocolo TCP/IP 4 ativo. Parece
bobeira, mas há algum tempo que me ferrei muito com uma VM que não
tinha/não precisava de acesso a rede e causava erros desconhecidos em
vários aplicativos por não ter ao menos 1 placa de rede com o
protocolo TCP/IP 4 ativo (era coisa do Windows XP, se não me engano).

7- Por fim, se nada disso ajudar, instale o PostgreSQL em outra
máquina - ou até em uma máquina virtual - com Linux, porque aí o
problema depende de muita fé para ser resolvido :)


TIAGO J. ADAMI
http://www.adamiworks.com
http://www.clouddba.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Mitos sobre PostgreSQL

[Tiago José Adami]

Em 28 de junho de 2016 11:07, Fábio Telles Rodriguez
 escreveu:
> Senhores, estou preparando uma palestra sobre PostgreSQL e gostaria de pedir
> uma mãozinha do pessoal aqui... Quais os maiores mitos que vocês conhecem
> sobre PostgreSQL?
>

"PostgreSQL não tem suporte".

Muitas empresas optam por Oracle, SQL Server e DB2 porque não conhecem
empresas ou profissionais que ofereçam suporte especializado do tipo
"'caiu' o servidor e o banco não 'levanta' mais!".


TIAGO J. ADAMI
http://www.adamiworks.com
http://www.clouddba.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] invalid page in block of relation base

[Tiago José Adami]

Em 20 de junho de 2016 10:34, Flavio Henrique Araque Gurgel
 escreveu:
>
> Você terá de utilisar outro programa, o memtester e não o memtest 86.
> Pra usar o memtest 86 você precisa espetar um pen drive, CD ou iso pra
> dar boot e ter acesso ao console. Não sei se seu fornecedor de serviços
> de hospedagem te permitirá fazer isso (que seria o ideal) então você
> instala o pacote memtester e roda esse cara (mas não é o melhor teste
> disponível).

O serviço utilizado é uma VM escalável /na nuvem/ e eu seriamente não
acredito que a LocaWeb tenha servidores com na sua "fazenda" com
memórias defeituosas (não querendo defender nem atacar, mas acho que
alguém da TI teria verificado isso antes).

Foi feito alguma mudança de plano que aumentou a quantidade de memória
e/ou o número de vCpus? Se isso ocorreu, o servidor (ou melhor, a VM)
foi desligada e religada ou a mudança foi "on-the-fly" e o SO ainda
não foi reiniciado?


TIAGO J. ADAMI
http://www.adamiworks.com
http://www.clouddba.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Qual a melhor forma de persistir uma senha no PostgreSQL?

[Tiago José Adami]

Em 20 de junho de 2016 18:38, Ronilson  escreveu:
> Boa noite.
>
> Sabendo que pretendemos trabalhar com senha criptografada, qual a forma mais
> segura de persistir esta senha no banco? Qual o tipo de dado mais
> recomendado, para este caso, no PosgreSQL?
>
>  Alguém pode me dar alguma dica? Sugerir algum artigo sobre o assunto?

A resposta é (como quase sempre): "depende".

O que você pretende fazer? Autenticar acesso de usuários?

Na maioria das vezes eu não armazeno as senhas criptografadas, mas
sim, um hash MD5 [1] das senhas utilizando a função md5 do PostgreSQL
em um campo CHAR(32). Depois comparo o hash da senha digitada com o
hash gravado no banco.

Não é o método mais seguro, mas na maioria dos casos atende muito bem.

[1] https://www.postgresql.org/docs/9.5/static/functions-string.html


TIAGO J. ADAMI
http://www.adamiworks.com
http://www.clouddba.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] (sem assunto)

[Tiago José Adami]

Em 17 de junho de 2016 09:33, Ursulino Barboza  escreveu:
>> BRT LOG:  could not receive data from client: No connection could be made
>> because the target machine actively refused it.
>>
>> BRT LOG:  unexpected EOF on client connection
>
> Os agentes ODI e o postgres 9.4 estão em Linux Red Hat.

Pela mensagem dá pra entender que em algum momento a conexão perdeu a
capacidade de enviar/receber dados do client e o PostgreSQL registrou
esta mensagem.

Apesar das mensagens, as conexões são interrompidas ou nenhum erro é
observado na(s) aplicação(ões)?

Pergunto, pois, como o Michel respondeu na mensagem anterior e pelo o
que tenho visto há muito tempo, estas mensagens "unexpected EOF on
client connection" não representam /realmente/ um problema. O simples
fato de rodar um 'kill -9' em um app conectado ao PostgreSQL pode
ocasionar esta mensagem no servidor.

Agora que mencionei isto, para encerrar, lembrei-me de um aplicativo
escrito em Powerbuider que ao invés de rodar um "disconnect" na
transação (conexão) apenas "matava" o objeto de transação, ocasionando
esta mensagem de EOF. Depois que fizeram o "disconnect" antes de matar
o objeto as mensagens cessaram. Tente investigar se não é algo
semelhante.

Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Problemas com ‘alternativas’ ao modelo relacional

[Tiago José Adami]

Em 10 de junho de 2016 14:03, Guimarães Faria Corcete DUTRA, Leandro
<l...@dutras.org> escreveu:
> 2016-06-09 23:32 GMT-03:00 Tiago José Adami <adam...@gmail.com>:
>>
>> Na verdade a maioria que conheço critica sem nunca ter usado e
>> defendem o modelo relacional/SQL para tudo. Radicais "SQLtremistas".
>
> Isso existe.  Mas veja que você está confundindo o modelo relacional
> com SQL; um é um conceito, outro uma implementação.  O que me parece
> que talvez alguns desses extremistas que acusam talvez tenham uma
> melhor compreensão das questões que a tua.

Antes fosse... mas no caso criticam porque não conhecem NoSQL e/ou têm
medo de perder seus empregos com SGBDR.

> Tentando explicar melhor: o SQL tem limitações, sim.  Mas o modelo
> relacional, não: o SQL tem várias restrições em relação ao modelo
> relacional, que é capaz de faze tudo o que se pode fazer com dados,
> por ser a única teoria de dados validada até hoje — na verdade, tem a
> dos grafos também, mas é muito mais limitada e complexa.
>
> Como já se disse à exaustão nesta lista e noutras, o que o NoSQL
> contribui é com técnicas de armazenagem e (ou) recuperação que,
> tipicamente, uma vez validadas, o PostgreSQL (e por vezes algum outro
> SGBD SQL) pode incorporar.  Talvez no final das contas as limitações
> inerentes ao SQL se tornem suficientemente importantes, e o
> conhecimento sobre o modelo relacional suficientemente amplo, para que
> abandonemos o SQL em favor de algo puramente relacional, o que
> facilitará ainda mais a incoroporação das técnicas de armazenagem e
> recuperação gestadas fora do mundo SQL.
>
> Pelo jeito, está na hora de lançar novamente meu desafio: quem critica
> o modelo relacional geralmente não o compreendeu.  E no Brasil há
> pouquíssimas pessoas que o aprendem na escola, porque geralmente ou os
> próprios professores não aprenderam, ou foram corrompidos pelas
> vantagen$ de se trabalhar com os fornecedores de sistemas
> proprietários SQL, infelzimente.  Portanto, vós que defendeis o NoSQL,
> desafio-vos: por favor, definam o que é o modelo relacional.
>
> E quem tiver tentado responder, acertado ou não, recomendo ler o
> artigo do Codd em que ele o delineia
> <https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf‎>, para ver a
> que situação ele respondeu ao criá-lo.  Quase meio século atrás.
>
> Por outro lado, minha crítica ao NoSQL é que, ao propagandear suas
> técnicas de armazenagem e recuperação, esquece-se de tudo o que o
> modelo relacional resolveu, como fica óbvio no caso em tela, e
> reinventa-se a roda mal e porcamente.  Ganha-se muito mais ao
> usarem-se essas técnicas no PostgreSQL, como demonstra uma simples
> busca <http://google.com/search?q=nosql+postgresql>.  Dependendo da
> situação, até o @#%$$%!#@$% do MySQL supera o NoSQL
> <http://blog.wix.engineering/2015/12/10/scaling-to-100m-mysql-is-a-better-nosql/>!
>
> Ou seja, trocando em miúdos: NoSQL é útil para quem tem uma
> necessidade que o PostgreSQL _ainda_ não cobre.  Como foi o caso de
> grandes provedores de serviço, mas dificilmente é o de alguém desta
> lista.  E mesmo para esses, a tendência é regularizar com o PostgreSQL
> ou algum outro SQL.  Só para dar mais um exemplo, o Google
> praticamente inaugurou essa moda com o famoso /map-reduce/; hoje, usa
> um serviço SQL sobre uma base (quase-)relacional, o F1 e o Spanner.  O
> Yahoo fez isso antes, com o Himalaia, baseado no PostgreSQL.

Além do teu desafio eu sugiro algo que possa direcionar os
profissionais (programadores, analistas e afins) que pensam em
primeiramente usar NoSQL sem conhecer melhor a implementação
relacional dos SGBDR. Seria viável? Puxando a brasa para o PostgreSQL,
criando tópicos incluindo tudo o PostgreSQL implementa que supre a
necessidade de uso do NoSQL, e também tudo o que não implementa.

Precisaríamos de pessoas que conhecem bem os dois lados da moeda. Tem
alguém disponível aqui na lista?


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Problemas com ‘alternativas’ ao modelo relacional

[Tiago José Adami]

Em 9 de junho de 2016 20:04, Everton B  escreveu:
> Acho que quando os DBAs criticam o MongoDB geralmente estão alertando
> novatos/startups hipsters de que ele não vai servir para o fim que eles
> geralmente desejam (...)

Na verdade a maioria que conheço critica sem nunca ter usado e
defendem o modelo relacional/SQL para tudo. Radicais "SQLtremistas".
Eu mesmo já fui assim. Hoje não digo nada, pois todos os aplicativos e
sistemas com os quais trabalho precisam de SQL/SGBDR, são todos
softwares CRM/ERP/WMS/HRM e financeiros.


>> E assim como outras tecnologias o NoSQL está evoluindo. Quem sabe em
>> um futuro próximo os bancos relacionais terão "plugins" ou módulos
>> adicionais com um armazenamento totalmente NoSQL (sem ter que usar a
>> linguagem SQL como transporte). Talvez até o PostgreSQL seja um dos
>> primeiros a implementar. Vai saber...
>
>
> Não sei se contempla o que vc quis dizer, mas já existe esta implementação
> no PostgreSQL:
> https://www.postgresql.org/docs/9.5/static/hstore.html

Quase isso. Já havia lido sobre hstore, mas ele ainda "pega carona" na
SQL. Imaginei um acesso paralelo totalmente NoSQL, sem precisar da
SQL. Mas foi só uma "mental diarrhea".

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Problemas com ‘alternativas’ ao modelo relacional

[Tiago José Adami]

Em 9 de junho de 2016 17:05, Fabrízio de Royes Mello
 escreveu:

> Isso vai depender de que problema de negócio vc quer resolver. Para um
> ERP por exemplo creio que um NoSQL possa não se aplicar devido a
> consistencia eventual. Imagina no sistema orçamentário de cada usuario
> visualizar um saldo diferente de uma conta pra fazer uma reserva
> financeira??? No final das coisa poderemos ter problema né. Porém qual o
> problema de dois usuários acessarem a mesma timeline de uma pessoa em
> uma rede social e uma delas nao visualizar o último post que foi feito
> instantes antes???
>
> Em TI tudo "depende"...

Perfeito. Estou muito centrado em RDBMS desde sempre e ainda não fui
me aventurar no mundo NoSQL. Esta explicação reforça muito a minha
percepção sobre quando e onde usar NoSQL (se algum dia for
necessário).

É muito importante aquilo que disseste na mensagem anterior, sobre não
existir ferramenta "bala de prata" que resolva todos os problemas.
Apesar de a maioria dos DBAs que conheço criticarem NoSQL é preciso
manter a mente aberta. A comparação NoSQL vs Relacional/SQL é
semelhante à comparação Laranjas e Maçãs. Ou melhor: Bananas e Maçãs.

E assim como outras tecnologias o NoSQL está evoluindo. Quem sabe em
um futuro próximo os bancos relacionais terão "plugins" ou módulos
adicionais com um armazenamento totalmente NoSQL (sem ter que usar a
linguagem SQL como transporte). Talvez até o PostgreSQL seja um dos
primeiros a implementar. Vai saber...


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Problemas com ‘alternativas’ ao modelo relacional

[Tiago José Adami]

Em 9 de junho de 2016 12:51, Guimarães Faria Corcete DUTRA, Leandro
 escreveu:
> 2016-06-09 12:47 GMT-03:00 Fabrízio de Royes Mello :
>> On 08-06-2016 14:55, Guimarães Faria Corcete DUTRA, Leandro wrote:
>>> https://engineering.meteor.com/mongodb-queries-dont-always-return-all-matching-documents-654b6594a827#.phpzbdxtf
>>
>> IMHO o problema descrito tem mais a ver com a forma como a ferramenta
>> implementa controle de concorrência do que o modelo de dados em si.
>
> É verdade, a rigor.  Mas veja que ‘não há almoços grátis’; quando
> alguém promete algo melhor que o relacional, geralmente o que fez foi
> gambiarra mesmo.
>

Eu nunca trabalhei com MongoDB ou NoSQL e até o momento não pretendo,
mas não posso perder uma oportunidade de aprender mais a respeito.

Já ouvi muito por aí que NoSQL facilita o trabalho em projetos que
tenham volumes de informação gigantescos incluindo dados complexos
(árvores, vetores, etc.) e que falhas de consistência são aceitáveis
seguindo a lógica de que "se 1 registro estiver errado dentro de 1
milhão, não faz diferença no resultado final".

Neste contexto, se for verdade que NoSQL é mais rápido e fácil de
implementar que SQL/Relacional, justificaria o seu uso. Ou não?


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
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ão de schemas

[Tiago José Adami]

Em 7 de junho de 2016 15:42, Guimarães Faria Corcete DUTRA, Leandro
 escreveu:
>> Na questão do OP, se algum ORM for utilizado com classes de entidade
>> estáticas no aplicativo não haverão muitos problemas - desde que os
>> novos atributos não sejam /not null/ e/ou tenham valores default.
>> Haveriam problemas caso atributos ou tabelas fossem eliminados.
>
> Certo.  Mas isso implica em restrições importantes, no caso serem
> entidades estáticas e todos os novos atributos terem valor padrão ou
> serem NULáveis — e o ideal é não ser NULável.

Concordo. Mas aí vai depender do contrato com o cliente para avaliar
quanto tempo é possível parar o ambiente para alguma atualização - com
tempo suficiente para atualizar todas as instâncias do App e também o
banco de dados. Caso contrário, é preciso se render a alguns NULLs.

ADAMI
___
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ão de schemas

[Tiago José Adami]

Em 7 de junho de 2016 15:16, Guimarães Faria Corcete DUTRA, Leandro
<l...@dutras.org> escreveu:
> 2016-06-07 15:10 GMT-03:00 Tiago José Adami <adam...@gmail.com>:
>>
>> Só é preciso cuidado especial com as ferramentas "geradoras de
>> código", aquelas que se baseiam na estrutura (catálogo) do banco de
>> dados para montar comandos SQL.
>
> O que inclui os famigerados ORM, certo?

Me referi a algumas soluções particulares, como geradores de
relatórios feitos 'no braço' ou algo assim. É comum ver este tipo de
solução nos aplicativos que conectam aos bancos que dou suporte. Eles
leem o catálogo para mostrar quais campos estão disponíveis e alguns
até criam views e functions baseados no catálogo.

Na questão do OP, se algum ORM for utilizado com classes de entidade
estáticas no aplicativo não haverão muitos problemas - desde que os
novos atributos não sejam /not null/ e/ou tenham valores default.
Haveriam problemas caso atributos ou tabelas fossem eliminados.

ADAMI
___
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ão de schemas

[Tiago José Adami]

Em 7 de junho de 2016 14:02, Felipe Santos  escreveu:
> Uma das ideias é que você apenas adicione novas estruturas
> (atributos,relações) ao seu banco de dados ao invés de modificar as
> existentes.
>
> Deste modo as novas versões do software entenderão as novas estruturas, sem
> quebrar as antigas versões, que continuarão lendo a estrutura antiga do
> banco de dados.

+1

Conheço vários aplicativos e sistemas que trabalham desta forma. Nada
é perfeito, uma ou outra vez ocorrem problemas, mas são pequenos e
pontuais.

Só é preciso cuidado especial com as ferramentas "geradoras de
código", aquelas que se baseiam na estrutura (catálogo) do banco de
dados para montar comandos SQL.

Depois, dependendo do caso, em versões futuras os atributos não
utilizados podem ser removidos programando com tempo uma manutenção
OFF-LINE - num feriado bem esticado, como de costume ;-)


ADAMI
___
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 em select

[Tiago José Adami]

Em 4 de maio de 2016 22:19, Jean Alysson  escreveu:
>
> Ola, preciso fazer o select abaixo, tem que retornar somente um registro,
> mas como o campoString é diferente, retornam varios registros, como posso 
> resolver ?
>
> SELECT  max(campoInteger), campoString
>  FROM tabela
>  where outroCampoInteger = 31
> group by campoInteger, campoString
>
> já tentei colocar max(campoString), mas não deu certo , retorna um registro, 
> mas misturou o campoInteger de um registro com o campoString de outro registro

Deduzi que você quer os dois campos para o valor máximo de
campoInteger, certo? Veja se isso te ajuda:

SELECT
t1.campoInteger, t1.campoString
FROM
tabela t1
WHERE
t1.outroCampoInteger = 31 AND
t1.campoInteger = (
SELECT
MAX(t2.campoInteger)
FROM
tabela t2
WHERE
t2.outroCampoInteger = t1.outroCampoInteger
)

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Como tratar a concorrencia Update x Select

[Tiago José Adami]

Em 02/04/2016 00:48, "Sebastian Webber"  escreveu:
> Nada impede fazer isso com um banco de dados pra todos os caixas. Essa
tua proposta parece boa num cenário de alta concorrência, mas fico com as
minhas dúvidas se a realidade do colega tem essa demanda.

Não tem relação com o PostgreSQL, mas se não me engano a lei do PAF/ECF
exige que todos os caixas tenham "bases de dados" individuais para
funcionarem de forma independente em caso de falha de comunicação com o
servidor.
Seria bom o OP verificar isso, já
resolveria 2 problemas de uma só vez.

Tiago J. Adami
Enviado do GMail / Android
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Como tratar a concorrencia Update x Select

[Tiago José Adami]

Em 1 de abril de 2016 13:33,   escreveu:
> Pessoal tenho uma função no sistema onde o usuario seleciona varios produtos
> e muda por exemplo a localização,
> imagine que seja 2mil produtos, neste momento o caixa está vendendo e aí
> trava,
> isso seria normal ou tem alguma coisa que posso mudar pra não travar o
> registro enquanto altera?
>
> Eu poderia travar no caixa lá é prioridade, pois o cliente já está com o
> produto na mão, mas lá é só select.
>
> Como o PostgreSQL trava essas concorrências?

Para responder esta pergunta são necessárias algumas informações:

1) Qual a versão do PostgreSQL utilizada?
2) Qual o nível de isolação (isolation level) utilizado nos caixas [1]?
3) O comando SELECT que busca o produto no caixa está utilizando a
cláusula FOR UPDATE?
4) O processo de venda atualiza o valor de alguma coluna na tabela de produtos?

O nível de isolação padrão é READ COMMITED. Neste caso você não teria
problemas exceto se há concorrência de UPDATE/DELETE sobre o mesmo
registro sendo alterado no cadastro e na venda.

[1] http://www.postgresql.org/docs/current/static/sql-set-transaction.html

TIAGO J. ADAMI
http://www.adamiworks.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Desempenho de índices

[Tiago José Adami]

Em 11 de março de 2016 16:46, Vinícius Aquino do Vale
 escreveu:
> Olá Danilo,
>
> Existe diferenças sim.
>
> Dê uma olhada neste post, para entender melhor a situação e o uso de índices
> compostos.

Este artigo que o Vinicius lhe recomendou já poderá lhe dar uma boa
ideia de como funciona o SGBD em relação aos índices.

Pode haver diferenças de desempenho significativas entre uma forma e
outra (me referindo ao tipos descritos pelo OP). Cito 3 principais
itens que interferem no desempenho dos índices:

1) a quantidade de distinções de um campo em relação às linhas. Em
outras palavras, quantas vezes o valor muda ao longo de todos os
registros;
2) a ordem dos campos no índice:  (campo1,campo2) ou (campo2,campo1);
3) as colunas utilizadas na consulta SQL. Se apenas os campos do
índice estiverem em uma consulta o acesso será "index only", sem a
necessidade de fazer um fetch adicional nos dados da tabela. Em alguns
casos é recomendável incluir um campo no índice - no final da lista de
colunas - para proporcionar um acesso "index only".

Bônus:

Já ia me esquecendo da clausula WHERE [1] nos índices do PostgreSQL,
que é fantástica! Nela você pode definir um predicado de consulta
específico que o PostgreSQL trata de forma indexada. Em determinadas
situações isto pode salvar vidas! :)

[1] http://www.postgresql.org/docs/current/static/sql-createindex.html

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] :: Ferramenta de Modelagem Free ::

[Tiago José Adami]

Em 9 de março de 2016 13:56, Guimarães Faria Corcete DUTRA, Leandro
 escreveu:
> 2016-03-09 13:55 GMT-03:00 Alexsandro Haag :
>> Em 09/03/2016 13:48, Wagner Vieira Furno - Lobotech escreveu:
>>>
>>> Qual ferramenta de modelagem free podemos utilizar para postgresql no
>>> momento ?
>>
>> SQL Power Architect - http://www.sqlpower.ca/page/architect_download_os
>
> A consulta original ficou ambígua —/free/ pode querer dizer livre ou
> gratuito—, então pergunto se é gratuito apenas ou também livre…

"Free" de livre mesmo, sob a égide da GPLv3.

https://github.com/sqlpower
https://github.com/SQLPower/power-architect

Na última release (v1.0.8) foram corrigidos vários bugs chatos. Eu
estou tentando ajudar no projeto, mas ainda não consegui configurar
todas as dependências (e o código parece aquela bela macarronada).

Parece que o projeto é um pouco "mal administrado". O pessoal demora
para responder - quando responde.

Se eu conseguir configurar as dependências corretamente, estou bem
interessado em criar um fork por causa dessa bagunça.

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Uso de índices x tamanho da tabela

[Tiago José Adami]

Em 29 de fevereiro de 2016 18:01, Neto pr  escreveu:
> Mas teria como saber um valor  (nem que for aproximado) de tamanho de
> tabela, em que seria interessante criar um índice (considerando o
> tamanho da ram como referencia)?

Não sei se entendi direito todo o seu questionamento, mas, mesmo que
toda a tabela esteja em memória o acesso a índice é muito mais rápido
que um tablescan, uma varredura completa sobre os registros da tabela
- considerando que ambos estão em memória.

Há alguns casos, claro, conforme o tipo da consulta, que o otimizador
julga um tablescan mais rápido que um indexscan. Isso pode acontecer,
por exemplo, quando você tem uma tabela com dados de produto (de 1 a
10, digamos) e você pesquisa todos os produtos de 1 a 9, excluindo
apenas o 10. Neste caso um tablescan será menos custoso que ter que
pesquisar o índice e depois buscar os registros na tabela (caso hajam
mais colunas na consulta além das existentes no índice). Essa função é
do otimizador interno, e pode ter certeza que ele é mais inteligente
que qualquer pessoa na hora de decidir isso (desde que as métricas
estejam bem atualizadas, portanto o VACUUM ANALYZE é essencial).

Um consenso praticamente unânime dentre os mais experientes da lista é
que otimização precoce é um tiro no pé. Você deve planejar índices
conforme o tipo das consultas que são executadas. Não existe uma
fórmula para dizer se você deve ou não criar um índice com base apenas
em informações de hardware do servidor, tamanho e estrutura das
tabelas.


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
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 incremental

[Tiago José Adami]

Em 1 de fevereiro de 2016 09:00, ChIcO  escreveu:
> Tenho dúvida se o pg_basebackup copia todos os arquivos ou apenas os
> alterados. Acredito que todos, então pode ser um pouco mais demorado q o
> rsync.

O pg_basebackup não faz cópias incrementais, cada vez que é executado
é feito uma nova cópia integral de todos os arquivos.

Como é um ambiente de homologação e testes supõe-se que os dados serão
alterados no ambiente de homologação, logo não há como manter uma
baseline sincronizada com o ambiente de produção através pg_standby
[1] - este faz a replicação dos logs transacionais (WAL).

Usar o rsync é possível, mas é um procedimento passível de erros
(permissões, espaço em disco, pontos de montagem, etc.). Para
utilizá-lo com segurança é preciso parar o serviço nos dois ambientes
antes de executá-lo e dependendo da SLA isto nem sempre é permitido.

[1] http://www.postgresql.org/docs/9.1/static/pgstandby.html

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
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 incremental

[Tiago José Adami]

Em 29 de janeiro de 2016 17:51, Luiz Henrique
 escreveu:
> Pessoal,
>
> Tenho Postgresql 9.1, Linux CentOS. 5 Databases. 1 Database tem 254
> GB.Preciso levar diariamente somente esse Database (254 GB) para outro
> servidor (homologação).O tempo de pg_dump / pg_restore leva cerca de
> 8h.Procuro alternativas para atualizar somente as diferenças do dia
> anterior. Sugestões e dicas serão muito bem vindas.

Para um ambiente de homologação manter uma replicação para "atualizar
somente as diferenças do dia anterior" não é a melhor alternativa,
pois espera-se que o banco de homologação receba alterações (INSERT,
UPDATE, DELETE).

Talvez um simples pg_basebackup[1] seja a melhor solução, considerando
que ambos os servidores (origem e homologação) possuem o mesmo SO e
mesma versão do PostgreSQL. O tempo para gerar um backup pelo
pg_basebackup em comparação com um dump (que não é exatamente um
backup [2]) é gritante, ao passo que é feito uma cópia dos arquivos
originais.

Lembrando que o pg_basebackup faz a cópia de todo o cluster, isto é,
inclui todos os bancos de dados nele criados.

[1] http://www.postgresql.org/docs/9.1/static/app-pgbasebackup.html
[2] http://savepoint.blog.br/dump-nao-e-backup/

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
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 PostgreSQL Windows Server 2012

[Tiago José Adami]

Em 27 de janeiro de 2016 14:54, Edinelson  escreveu:
> Dei olhada no servidor  e serviço PostgreSQL esta parado.
> No servidor tem mensagem erro quando foi ativar serviço =>2016-01-27
> 13:21:50 BRT FATAL:  diretório de dados "V:/PHO/PostgreSQL" não existe
>
> "Euler Taveira"  escreveu na notícia da
> mensagem:56a8ef76.5090...@timbira.com.br...
>
>
> On 27-01-2016 12:58, Edinelson wrote:
>>
>> psql: não pôde conectar ao servidor: Connection refused (0x274D/10061)
>>O servidor está executando na máquina "localhost" (::1) e aceitando
>>conexões TCP/IP na porta 5432?
>> não pôde conectar ao servidor: Connection refused (0x274D/10061)
>>O servidor está executando na máquina "localhost" (127.0.0.1) e
>> aceitando
>>conexões TCP/IP na porta 5432?
>>
> Verifique se o serviço do postgres está executando após a falha da
> instalação. Se sim, algum firewall ou anti-algumacoisa está bloqueando a
> conexão na porta 5432.

Seguindo a dica do Euler, antes de instalar desabilite o firewall do
Windows e outros aplicativos de antivírus/firewall que possam estar em
execução no servidor, isto já irá descartar a possibilidade de ser
algum deles interferindo.

Depois, siga as instruções:

1) Desinstale completamente o PostgreSQL;
2) Vá até o Windows Explorer e remova a pasta V:\PHO\PostgreSQL;
3) Crie novamente a pasta V:\PHO\PostgreSQL;
4) Clique com o botão direito sobre a pasta V:\PHO\PostgreSQL, clique
na aba "Security" (Segurança) e clique no botão "Advanced" (Avançado);
5) Na tela a seguir, clique no botão "Modify Permissions" (Alterar Permissões);
6) Clique no botão "Add" (Adicionar) e inclua na lista o usuário
"NETWORK SERVICE" (SERVIÇO DE REDE)  e dê-lhe permissão de controle
total sobre a pasta - estes nomes estão em caixa alta mesmo;
7) Certifique-se que o grupo "Administrators" (Administradores) e
"SYSTEM" (SISTEMA) estão com controle total de acesso também.
8) Antes de clicar em OK, marque o único flag da aba "Permissions"
(Permissões) que fica abaixo - em português está como "Substituir
todas as entradas de permissão de objetos filho por entradas de
permissão herdáveis desse objeto";
9) Clique em OK e confirme a caixa de mensagem que irá aparecer;
10) Instale o PostgreSQL informando o caminho V:\PHO\PostgreSQL como
diretório de dados.

Isto deve resolver.

Tiago J. Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramentas para Gerenciar Regras de negocio no banco de dados

[Tiago José Adami]

Em 19 de janeiro de 2016 10:59, Guimarães Faria Corcete DUTRA, Leandro
<l...@dutras.org> escreveu:
> 2016-01-18 19:57 GMT-02:00 Tiago José Adami <adam...@gmail.com>:
>>
>> Regras de validação de campo, por exemplo, você poderá (deverá) fazer no
>> banco para garantir a integridade dos dados. Mas também precisará ter algo
>> no front-end para diminuir o tempo de resposta e distribuir mesmo que pouca
>> coisa o processamento.
>
> Isso é otimização precoce.  Geralmente não é o caso; geralmente, o
> tempo de resposta e a distribuição ficam melhores com as regras
> declaradas no banco; a segunda melhor situação é quando não dá para
> declarar tudo, e precisa também usar o famoso ‘código procedural’, mas
> ainda no banco.

Discordo. Vejo duas formas de validar campos no banco de dados (se
houverem mais alternativas, por gentileza elucidem-nas):
1) por restrições ou gatilhos que serão validados no momento de
inserir/alterar um registro;
2) por uma função no banco que pode ser chamada quando o usuário
transfere o foco de um campo para outro.

A primeira opção não prioriza a usabilidade. É semelhante àquelas
páginas WEB com zilhões de campos que só te indicam que você errou
quando você faz o envio (submit). Cada submit do usuário ocasionaria
um erro de banco que deveria ser tratado na aplicação. Se o usuário
errou na entrada de 5 campos, teria que dar 5 submits para corrigir
todos os campos, pois o banco de dados já pára na primeira constraint
que falhou e interrompe a transação. Isto aumenta o tráfego
desnecessariamente e aumenta o tempo para submeter o formulário.

A segunda opção causará maior tráfego de dados e CPU no servidor se a
cada evento de passar o foco para outro campo o campo anterior seja
validado através de uma função no banco. Imagine um usuário
pressionando TAB em um formulário sem parar...

Ambos os casos são ruins para clientes (aplicações cliente) que usam
conexões de baixa velocidade e/ou alta latência.


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Schema ou Database distintas?

[Tiago José Adami]

Em 18 de janeiro de 2016 10:01, Felipe Moura  escreveu:
> Pessoal, estamos passando por um situação onde a equipe de banco de dados 
> afirma que trabalhar com esquema no postgres é inseguro e a solução dada 
> seria utilizar uma database para cada sistema.
>
> Alguém já passou por algo parecido?

Depende muito dos conceitos de segurança que a equipe possui. Se
estivessem falando de mais de um database para clientes separados,
onde o esquema do banco é o mesmo, existiriam mais variáveis a serem
consideradas (e mesmo assim não haveria insegurança dadas as
possibilidades de criar um usuário diferente e aplicar os GRANTs
corretamente).

Dou suporte em alguns bancos que tem mais de 20 esquemas, um para cada
departamento. Até hoje nenhum problema com acessos indevidos ou baixo
desempenho por causa disto.

> Também foi argumentado que os relacionamentos entre bases poderia ser feita 
> com dblink sem perda de performance e sem prejudicar futuros relatórios.

Com o DBLink você está adicionando uma camada adicional de comunicação
e na melhor das hipóteses você terá apenas alguns milissegundos de
overhead por requisição. Mas na prática não é mais rápido que acessar
uma tabela do próprio banco de dados alocada no mesmo espaço de
memória que as outras em uso.

Tiago J. Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Oferta de trabalho PostgreSQL na Alemanha - Com visto para trabalho

[Tiago José Adami]

Olá pessoal.

Recentemente fui contactado via LinkedIN por um recrutador chamado
Sebastian White. Ele está procurando um profissional em PostgreSQL que
tenha bons conhecimentos em otimização, upgrades, incidentes e shell script
(Python é um "plus a mais") para trabalhar em Berlin, sendo necessário
inglês avançado/fluente.

Eu não conheço o Sebastian, apenas troquei alguns e-mails com ele. Não
parece ser uma falsa proposta, inclusive as entrevistas iniciais serão
feitas por Skype. Confesso que fiquei muito interessado na proposta, mas
por motivos pessoais não posso sair do Brasil e não segui adiante.

Logo, quem possuir interesse entre em contato com Sebastian pelo LinkedIN:
https://www.linkedin.com/in/sebastian-white-13272b26

...ou envie um e-mail solicitando mais informações sobre a vaga ao
endereço: sebastian -at- stelfox -dot- ie

Abaixo conteúdo do e-mail que recebi:

"""
I am working on behalf of Delivery Hero based in Berlin(English speaking),
one of the largest online food ordering companies in the world, now
operating on 3 continents with 15 million monthly transactions and 1600
staff.

Their DBA team is need of a postgresql champion, who has been using it
competently for the last few years in a Linux environment. Optimization,
upgrades, provisions and incidents will be all daily challenges, and you
will get to work in a talented and vibrant IT department. Some scripting
work in Bash and python will also come up
http://career.deliveryhero.com/

The company offer visas, relocation assistance, company benefits like
insurance, new hardware, social events and tech days. Also the chance to
work in Europe's silicon valley, the epicentre of Europe's start up
revolution.

If you know anyone who would be interested in this great new working
opportunity, please let me know, and I will contact them.

All the best and thanks for your time!

Sebastian

Sebastian White
01 679 3182 | sebastian -at- stelfox -dot- ie
"""

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramentas para Gerenciar Regras de negocio no banco de dados

[Tiago José Adami]

Em 18/01/2016 19:35, "Douglas Fabiano Specht" 
escreveu:
>
>
>
> Em 18 de janeiro de 2016 14:08, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:
>>>
>>> 3-Qual linguagem voces recomendariam para desenvolver essas Regras de
>>> negocio? Pgsql, Java, Perl, Phyton, C?
>>
>>
>> Eu só gostaria que parassem de chamar linguagem procedural de regra de
negócios.
>
>
> Mas linguagem procedural é para criar regras de negocio de uma aplicação
no banco.
> Digamos validação de CNPJ ou de telefone, nao vou ter isso na nossa
aplicação delphi e sim no banco de dados em algum linguagem, perl,
java,pgsql, etc..

Agora chegamos em um ponto interessante da discussão:
Regras de validação de campo, por exemplo, você poderá (deverá) fazer no
banco para garantir a integridade dos dados. Mas também precisará ter algo
no front-end para diminuir o tempo de resposta e distribuir mesmo que pouca
coisa o processamento.

O que eu vejo de toda a discussão só reafirma meu pensamento inicial: ter
tudo no banco ou tudo na aplicação não parece ser a melhor saída quando há
inúmeras ferramentas que agilizam um ou outro lado. Geralmente - e não
estou apontando para alguém aqui na lista - alguém decide pôr tudo em
apenas um lado porque não conhece o outro.

Acredito que nada pode ser decidido sem uma grande avaliação dos requisitos
da aplicação/sistema, bem como o seu ambiente de execução.

Tiago J. Adami
Enviado do GMail / Android
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

[Tiago José Adami]

Em 14/01/2016 18:25, "Saraiva Silva"  escreveu:
>
> Isso é um assunto recorrente no meio da comunidade de desenvolvimento, e
é quase unanimidade entre desenvolvedores a contrariedade em deixar as
regras de negocio no banco. Mas eu nunca vi a opinião de DBAs a respeito.
>

Minha opinião como DBA e Dev:

Prós:
- ganhos de desempenho em procedimentos complexos;
- centralização das regras, disponível para qualquer aplicação em qualquer
tecnologia (desde que possua drivers de conexão ao banco);
- possibilidade de controle de acesso por usuário do SGBD;
- atualizações são mais rápidas (basta atualizar via script);
- o aplicativo será apenas um front-end, mais leve e mais rápido;

Contras:
- você precisará de no mínimo dois dois bancos para fazer testes
regressivos e ser produtivo;
- em procedimentos longos é mais difícil (mas não impossível) obter o
retorno na aplicação sobre o status de execução (ex: "11% concluído").
- falta de mão de obra qualificada;
- se a aplicação tem o requisito de usar mais que um SGBD (aplicativos que
ficam hospedados no cliente ou por conta dele,  SAP, TOTVS, CISS, por
exemplo), torna-se uma dor de cabeça manter a mesma funcionalidade em
linguagens de banco diferentes: Pl/PgSQL, T-SQL, SQL/PL, etc.;
- se no meio da regra é necessário consultar um agente ou recurso externo,
tipo web service, outro banco de dados, um arquivo em disco, etc., a
complexidade aumenta muito, talvez fique impossível;
- muito mais difícil fazer debug;

Minha opinião pessoal é que tudo o que seja crítico em desempenho rode no
banco. O resto depende de muitos fatores e precisa ser discutido em equipe.

Tiago J. Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Regras de negocio no banco ou na aplicação

[Tiago José Adami]

Em 14/01/2016 19:12, "Fábio Telles Rodriguez" 
escreveu:
>
>
>
> Em 14 de janeiro de 2016 18:25, Saraiva Silva 
escreveu:
>>
>> Isso é um assunto recorrente no meio da comunidade de desenvolvimento, e
é quase unanimidade entre desenvolvedores a contrariedade em deixar as
regras de negocio no banco. Mas eu nunca vi a opinião de DBAs a respeito.
>
>
> Acho que tenho hoje praticamente a mesma opinião de 10 anos atrás quando
escrevi isso:
>
> http://savepoint.blog.br/inteligncia-em-bancos-de-dados/
>

Perfeito. Expressa muito bem minha opinião.

Tiago J. Adami
___
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 pg_dump

[Tiago José Adami]

Em 26 de novembro de 2015 11:19, Fábio Telles Rodriguez
 escreveu:
> Vale à pena lembrar que o PostgreSQL nasceu no mundo UNIX e neste universo,
> usar nomes de arquivos e diretórios com espaços... é uma péssima ideia.

No "mundo Windows" facilitaria se os empacotadores da EnterpriseDB
(desconheço se há algum outro empacotador) mudarem as diretrizes do
local padrão de instalação onde você escolhe apenas a unidade lógica
de disco - e a instalação seria feita em uma pasta padrão, digamos
"X:\PostgreSQL", "X:\pgsql" ou "X:\postgres", onde X é uma unidade
lógica escolhida.
Enquanto isso, durante a instalação sempre é possível mudar o local.
Eu sempre uso "X:\PostgreSQL". :)

>Sem os espaços você não precisa das aspas ou caracteres de escape.

Perfeitamente. Não ficou clara a minha resposta, deu a entender que
sempre é necessário inserir aspas duplas para identificar qualquer
caminho, o que não é correto. As aspas são necessárias apenas quando
há espaço no(s) nome(s) de arquivo(s) e pasta(s) envolvido(s) no
comando. Agradeço pela correção.


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Base corrompida

[Tiago José Adami]

Em 24 de novembro de 2015 17:23, Fabrízio de Royes Mello
 escreveu:
> Um detalhe *EXTREMAMENTE* importante antes de fazer qualquer coisa, pare
> o seu PostgreSQL e efetue uma cópia física do $PGDATA (e tablespaces se
> tiver) antes de mais nada.
>
> Como se trata de Windows, se este tiver um "antivirus" veja se aquele
> objeto que não foi encontrado não está na "quarentena" do mesmo.

Além do antivírus confirme se as permissões do diretório não foram
alteradas, no Windows é fácil de cometer deslizes deste tipo,
principalmente instaladores de certos tipos de programas que pedem
acesso de Administrador - Cobian Backup é um deles que já me deu
alguma dor de cabeça.

Extra: em algum momento da minha vida profissional já vi mensagem de
erro semelhante em uma tabela que residia em um disco particionado com
FAT32. Apesar dos bloqueios nos novos instaladores do PostgreSQL para
Windows, sabe-se-lá-quem-e-como conseguiu realizar esta façanha. E
então a tabela - ou arquivo do objeto - chegou no limite dos 4 GB e
'corrompeu' (se é esta a palavra adequada). Não testei hoje nas
versões mais atuais para dizer se isto ainda é possível e se a
mensagem é a mesma.


Tiago J. Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Base corrompida

[Tiago José Adami]

Em 24 de novembro de 2015 23:39, Dickson S. Guedes
<lis...@guedesoft.net> escreveu:
> Em 24 de novembro de 2015 20:16, Tiago José Adami <adam...@gmail.com> 
> escreveu:
>> E então a tabela - ou arquivo do objeto - chegou no limite dos 4 GB e
>> 'corrompeu' (se é esta a palavra adequada).
>
> Que estranho isso, porque o Postgres cria arquivos de tamanho menor ou
> igual a 1GB justamente por questões de compatibilidade. Vide o
> `relfilenode`, que é um ID lógico, fisicamente dividido em N arquivos
> físicos com tamanhos de no máximo 1GB nomeados com final .1, .2, .3, e
> assim por diante.

Faz muito tempo que eu presenciei este fato, difícil lembrar.

Pode parecer algo sem noção: a mensagem era semelhante, o arquivo
informado tinha 4 GB e estava dentro da pasta "..\base\", acredite ou
não, em uma partição FAT32 - equipamentos rodando Windows XP de
POS/Frente de Caixa de supermercados com uma tentativa de solução
utilizando PostgreSQL "embarcado'.

Agradeço pela observação sobre o meu comentário e não nego a
possibilidade de eu estar confundido e ter viajado legal na maionese.
Como não posso verificar, provar ou simular, melhor ignorar.

P.S: Para ficar menos feio o OP poderia verificar se a partição é
mesmo NTFS, já que é mais fácil corromper arquivos em FAT32 :)

Tiago J. Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Tipos de dados

[Tiago José Adami]

Em 21 de novembro de 2015 11:26, Osvaldo Kussama
 escreveu:
> Em 21/11/15, Luciano Reis escreveu:
>> Bom dia pessoal, eu fiz uma busca sobre tipos de dados para campos
>> específicos no PostgreSQL para gravar CEP,CPF, CNPJ, telefones e valores
>> monetários e encontrei opiniões muito diversas uns defendem que CPF tem de
>> ser guardado como string outros não.
>> É um primeiro projeto que eu vou iniciar usando o PostgreSQL e não sei
>> tomar essa decisão, como não encontrei nada concreto e fundamentado estou
>> recorrendo a comunidade.
>
> Creio que todos estes campos sejam numéricos e portanto devem ser
> armazenados como números (inteiro ou decimal de precisão arbitrária).

Eu pratico a seguinte regra: mesmo que o valor seja numérico, se não
for utilizado para cálculos matemáticos e não for monetário, eu
prefiro armazenar em VARCHAR, e geralmente com um limite maior do que
o atributo exige: para CPF e CNPJ eu uso VARCHAR(20), por exemplo.

Já me deparei com casos onde todos os envolvidos no projeto juravam
que não poderia haver caracteres - não númericos - no valor, como por
exemplo RG e conta bancária. De repente apareceram identificadores de
RG antigos com uma letra e contas de um banco que tinham um "X" como
dígito verificador.

Esta abordagem permite gravar "lixo" no campo, como os traços, pontos,
etc. Mas ainda prefiro criar e manter uma validação para proibir os
caracteres inválidos do que correr o risco de ter que alterar o tipo
da coluna e as variáveis de programa (aplicativos e sistemas) no
futuro.

Tiago J. Adami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Sobre Trigger PostgreSQL 9.4.5

[Tiago José Adami]

Em 18 de novembro de 2015 22:24, José Henrique Beraldo
 escreveu:
>
> Opa Tiago, boa noite. Desculpe não retornar antes.

Olá José. Descartei o código anterior para diminuir a resposta.

No código que você enviou não justifica o uso do campo
"tf_confirmacao_trigger_pai_id". Da forma como está, o trigger da
tabela filha sempre irá gravar o valor inserido na pk da tabela pai, e
tanto "tf_confirmacao_trigger_pai_id" quanto "tf_tb_id" terão os
mesmos valores.

Eu não entendi qual a motivação ou a regra por detrás de tudo isto,
mas parece ser um erro grosseiro de projeto. Seria interessante
revisar esta parte do modelo. Mas como provavelmente trata-se de um
software legado, nem vamos discutir este ponto pois talvez não seja
possível mudar muita coisa - já me deparei muito com casos assim.

Sobre o comportamento descrito na versão 7.4 possivelmente era um bug
e foi corrigido. Não faz muito sentido o campo auto-incremento
recuperar o valor da sequência em NEW antes do registro ser inserido
(BEFORE INSERT). Tanto que para fazer funcionar o seu código,
inserindo o valor "tf_confirmacao_trigger_pai_id" na tabela filha com
o mesmo valor da chave primária da tabela pai, basta alterar o trigger
da tabela pai para AFTER INSERT:

CREATE TRIGGER tab_pai_tr
  AFTER INSERT
  ON qion.tab_pai FOR EACH ROW
  EXECUTE PROCEDURE public.f_tab_pai();

Outra coisa: a menos que você queira fazer um teste para verificar se
o valor é nulo e abortar a transação, utilize RAISE NOTICE ao invés de
RAISE EXCEPTION.

RAISE NOTICE 'rRecord.tp_id % tp_data %',rRecord.tp_id,rrecord.tp_data;


--
TIAGO J. ADAMI
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Sobre Trigger PostgreSQL 9.4.5

[Tiago José Adami]

Em 17/11/2015 8:16 PM, "José Henrique Beraldo" 
escreveu:
>
> Boa noite.
> Estou fazendo uma manutenção em um banco de dados 7.4 que foi migrado
para o 9.4, e o comportamento das triggers mudou.
> O que percebi é que triggers que funcionam no 7.4 se comportam diferente
na versão 9.5, por exemplo:
> 1) quando a tabela pai tem uma trigger que escreve na tabela filho, e a
tabela filho, normalmente tem uma foreign key do pai, ai dá o erro de
verificação da constraint.
> Outro problema que ví, é que na trigger before do pai, ele escreve na
tabela filho, e na tabela filho tem uma trigger after que precisa coletar o
registro que ainda está em New da tabela pai, e esse registro não é
encontrado, diferentemente do 7.4.
> Preciso reescrever ou há alguma coisa que possa fazer?
> Obrigado.
>
Pelo o que entendi, se o disparo "do" trigger (tradução: gatilho) na tabela
pai for Before Insert, este comportamento é esperado.

A solução que imagino é alterar o trigger para after Insert na tabela pai.
Poste o código para que eu e os demais colegas da lista possamos visualizar
uma possível solução, só pela explicação ficou um pouco difícil de
entender.

Tiago J. Adami
___
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] Only NoSQL

[Tiago José Adami]

Em 6 de novembro de 2015 10:13, Matheus Saraiva
 escreveu:
> Bem, lá vai a opinião de alguém bem menos experiente do que todos que
> participaram desse off, aja vista que eu não sou dba, apenas dev.

Eu sou um misto de dba e dev, conheço pouco - ou nada - NoSQL e
gostaria de exemplificar um caso real que acompanhei de perto.

> Eu realmente não posso aqui debater a possibilidade de uma migração para
> 100% NoSQL, visto que ainda sei pouco sobre esse método de armazenagem e
> gerenciamento de dados.

Eu acredito que posso dar um "pitaco".

> Mas, hoje em dia ainda existem, e em quantidades razoáveis, grandes sistemas
> rodando em tecnologias descontinuadas como cobol, dbase, dataflex, clipper,
> etc. Algumas redes bancárias ainda hoje tem seus sistemas rodando em cobol.
> A coisa ficou tão funcional, tão estável que eles não se atrevem a fazer uma
> migração para uma solução relacional.

Muitas destas tecnologias armazenavam informações sob o conceito de
linhas e colunas, e, apesar de não incorporarem nativamente um SGBDR
não podem ser consideradas NoSQL. Não é possível armazenar objetos
complexos, como um objeto JSON repleto de atributos multivalorados em
arrays sem ter uma definição prévia (quantos atributos, tipo de
atributos, etc.). No caso do Cobol e Clipper (.DBF) é possível até
executar instruções SQL SELECT sobre o conjunto de tabelas/arquivos,
portanto, aproximam-se mais do modelo relacional do que NoSQL.

> A questão que levanto é, se esse casos de uso, conseguem viver sem o modelo
> relacional e ter soluções satisfatórias, mesmo usando tecnologias
> descontinuadas à décadas. Por que, o NoSQL, na figura do mongoDB, casandra,
> etc, que são soluções mais atuais e de desenvolvimento e comunidade ativos
> não podem ser também usadas como único sgdb de forma satisfatória?

As tecnologias antigas citadas anteriormente não chegam perto dos
conceitos de NoSQL atuais. E, de fato, trabalhei para o HSBC há alguns
anos. Lá pelo menos é usado SGBDR em tudo. A parte em Cobol puro é
utilizada para aplicações críticas que demandam processamento "quase
real" e depois todas as informações são exportadas e armazenadas em
bancos relacionais (Oracle e Sybase ASE).

Apesar de eu nunca ter trabalhado com NoSQL participei de um time de
desenvolvimento para uma empresa que estava indo fundo em um projeto
que, à exemplo do OP, queria mesclar NoSQL com SGBDR. Eu, obviamente,
fiquei no "subtime" do SGBDR. O time de desenvolvedores (Java) por
muito tempo ficou excitado com as novas possibilidades usando MongoDB,
pouca demanda era repassada para a minha equipe e muitas
justificativas de usar o MongoDB (como desempenho, facilidade de
programação, etc.) eram dúbias (tudo era possível ser feito em SGBDR).

Lembro-me bem de um programador que dizia que "trabalhar com NoSQL era
tão fácil quanto abrir um arquivo texto e inserir informações neles".
Eu muito questionei como estes dados seriam consistentes depois, como
seriam feitas as consultas, como garantir que uma informação de uma
entidade (ou objeto para eles) estaria realmente gravada no banco de
dados. As respostas sempre eram as mesmas: isso a aplicação irá
resolver, a aplicação precisa estar bem desenvolvida e bem testada.

Passaram pelo menos 4 anos desde que este projeto começou e ainda não
terminou. A complexidade tornou-se tão enorme que para criar um
"módulo" simples, um CRUD, são necessários pelo menos 4 dias. Depois
de milhares (senão milhões) de reais gastos, o projeto dá sinais de
que será abandonado.

E a integridade de informações? Bem, o mesmo programador me disse que
é um inferno na terra, que depois de um certo número de registros
(ops, objetos) armazenados as consultas NoSQL são enormes tratando
diversos tipos de atributos que podem ou não existir, muito lixo é
armazenado e também há o caso do "programa bem desenvolvido e bem
testado" que nunca existe, trazendo muito mais dor de cabeça que
benefícios.


> Será as
> soluções NoSQL atuais tão ruins assim que conseguem ser piores do que
> tecnologias descontinuadas à várias décadas?

Para transportes terrestres não vi nada mais eficiente que rodas sob
os veículos para permitir a locomoção. O ponto que quero chegar é que
existem tecnologias e conceitos tão maduros que não precisem ser
recriados, apenas aperfeiçoados. Clipper, por exemplo, foi o
predecessor do FoxPro e do Visual FoxPro que já utilizavam SGBDRs
rudimentares nativamente (se não me engano até existia um plugin
OraClipper para acessar bancos Oracle no Clipper Summer 87, mas já não
lembro). Com todas as novas implementações dos SGBDRs permitindo o
armazenamento de objetos JSON e dados complexos, não vejo motivo algum
para usar NoSQL. Isso é modinha à exemplo do Cachè antigamente, que
tinha até propaganda na Revista Info.

Mas quem quiser tentar, vai fundo e compartilha a experiência!



TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list

Re: [pgbr-geral] descobrir se telefone é celular

[Tiago José Adami]

> O problema é que o campo está sem mascara e telefones convencionais juntos,
> ou seja aquela bagunça de sempre,
> exemplo:
> 48-
> 49--
> 049--
> (49)-
> (49)
>
> por isso queria ver se alguem tinha alguma função para compartilhar, algo do
> tipo regex, pois não consigo entender como funciona essa parada.

Opa, veja se isso te ajuda. São duas funções: uma para formatar os
números removendo caracteres não numéricos e a outra que compara e
verifica se é um número de telefone móvel começando com os dígitos 8
ou 9 (considerando que esta é a regra):

CREATE OR REPLACE FUNCTION uf_format_phone_number(
a_number BPCHAR
)
RETURNS BPCHAR AS
$BODY$
DECLARE
lc_number BPCHAR;
lc_char   BPCHAR;
li_len INTEGER;
BEGIN
li_len := LENGTH(a_number);
lc_number := '';

FOR i IN 1..li_len LOOP
lc_char = SUBSTR(a_number,i,1);

IF POSITION(lc_char IN '0123456789')<=0 THEN
CONTINUE;
END IF;

lc_number := lc_number || lc_char;
END LOOP;

lc_number := CAST(CAST(lc_number AS NUMERIC(20,0)) AS BPCHAR);

RETURN lc_number;

END;
$BODY$
LANGUAGE 'plpgsql' IMMUTABLE;


CREATE OR REPLACE FUNCTION uf_is_mobile_number(
a_number BPCHAR
)
RETURNS BOOLEAN AS
$$
SELECT uf_format_phone_number(a_number) ~ '^[1-9]{2}[8-9][0-9]{7,8}$'
$$
LANGUAGE SQL;

Eu fiz estas funções conferindo a explicação de um post no
StackOverflow [1] sobre regex para o mesmo fim.

Para verificar se um número é ou não de telefonia móvel, use a função
'uf_is_mobile_number':

SELECT uf_is_mobile_number('(099)-');


Referências:
[1] 
http://pt.stackoverflow.com/questions/46672/como-fazer-uma-express%C3%A3o-regular-para-telefone-celular


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] PGDay em Curitiba dia 18 de setembro

[Tiago José Adami]

Em 10 de setembro de 2015 13:57, Alisson Coelho de Morais
 escreveu:
> Pessoal, está chegando a hora... será na próxima semana, UTFPR (antigo
> CEFET).
>
> O PGDay é um evento gratuito, mas para participar, é preciso fazer inscrição
> no site do FTSL [1].

Estou aguardando autorização da minha chefia para participar (somente
dia 18 para o PgDay). Alguém saberia responder se as credenciais serão
entregues também no dia 18?

TIAGO J. ADAMI
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Banco read-only

[Tiago José Adami]

Em 4 de setembro de 2015 16:06, Luiz Carlos L. Nogueira Jr.
 escreveu:
>
> Eu só queria que nenhum usuário pudesse escrever no banco.
> Coisa simples. Sem replicação nem nada.

Se "no banco" trata-se de um banco de dados único que possui acesso
controlado e gerenciado devidamente, inclusive ao sistema operacional
onde ele está instalado, basta permitir e divulgar apenas os acessos
dos usuários comuns (não superuser) que tenham direito de leitura
sobre as tabelas e direito de execute sobre as funções desejadas.


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Quais discos usar ?

[Tiago José Adami]

Em 30 de julho de 2015 15:45, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:

 2015-07-30 15:08 GMT-03:00 Raphael Coutinho rcoutosi...@gmail.com:
  Pelo que vi a vida útil do SSD é bem inferior.

 Não existe ‘o’ SSD.  Há uma enorme variedade de marcas, linhas e
 modelos, em toda faixa de custo e com todo tipo de característica
 diferente.  É claro que você não vai colocar unidades feitas para
 jogadores de videojogos…


  Vi análises citando 2-3 anos.

 Que análises, de que modelos?

 De qualquer maneira, Raid 1 com um estepe deve ser mais do que
 suficiente mesmo que dure apenas dois anos.  O ganho de desempenho
 vale a pena, geralemente, para tão poucos dados.

Para saber sobre a durabilidade de um SSD para servidores só entrando
em contato com o fabricante. Já ouvi de técnicos da Dell dizerem que
os SSDs comercializados por eles (marca Samsung) tem vida útil de mais
de 2 milhões de horas. Porém eles não consideram a quantidade de
escritas, que é o que gasta o SSD.

Agora, tenha em mente que o custo de um SSD para servidor é alto.

Talvez você possa investir em 2 discos de SAS 15.000 RPM para
configurar um RAID 1 e aumentar significativamente a quantidade de
memória RAM para melhorar o desempenho. Ainda assim pode não chegar ao
preço de apenas 1 SSD com tamanho equivalente ao SAS. O preço varia
conforme a capacidade e marca.


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] REF: Chamar Função dentro da Trigger.

[Tiago José Adami]

Em 8 de julho de 2015 17:56, PAULO pa...@visualpsistemas.com.br escreveu:
 É possível chamar uma função dentro de uma Trigger ?

Dentro do trigger somente uma função pode e deve ser chamada [1]. Esta
função precisa retornar um tipo determinado [2] chamado trigger.

Os gatilhos no PostgreSQL não incluem código procedural à exemplo de
outros bancos de dados, elas contém o apenas o cabeçalho que faz
referência ao evento em que ocorre e qual a função deve ser chamada.
Nesta função que retorna um tipo trigger você pode fazer chamadas a
outras funções, é nela que fica o código procedural.

Veja o código de exemplo:

-- Cria a função que será usada no gatilho.
-- É nesta função que você faz as chamadas às outras funções
CREATE FUNCTION tf_trigger_function()
RETURNS trigger AS
$body$
BEGIN
-- Aqui fica o código procedural com a chamada a outras funções
RETURN NEW;
END;
$body$
LANGUAGE plpgsql;

-- Aqui o trigger apenas faz a chamada à função
-- criada acima.
CREATE TRIGGER tr_bu_trigger
BEFORE UPDATE ON tabela
FOR EACH ROW
EXECUTE PROCEDURE tf_trigger_function();



[1] http://www.postgresql.org/docs/9.1/static/sql-createtrigger.html
[2] http://www.postgresql.org/docs/9.1/static/plpgsql-trigger.html
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Carga de dados

[Tiago José Adami]

Em sábado, 23 de maio de 2015, Danilo Silva danilo.dsg.go...@gmail.com
escreveu:

 Pessoal,

 Considerando a versão 9.3, realmente é indicado executar um vacuum analyse
 após grandes cargas de dados?


Se a tabela possuía muitos registros antes da carga de dados, eu diria que
o VACUUM ANALYZE seria uma boa.

Se a tabela estiver vazia antes da carga apenas o ANALYZE é suficiente.

Tenha em mente que o VACUUM trabalha em uma forma semelhante à
desfragmentação de disco (explicando de uma forma grosseira).  Então é bom
rodar de vez em quando em tabelas que recebem muitos updates e deletes, a
periodicidade varia caso a caso.

Tiago Adami


-- 
Enviado do Gmail para iPhone
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Parâmetros de instalação

[Tiago José Adami]

Em 17 de maio de 2015 22:32, Junior Miranda
flmirandajun...@gmail.com escreveu:
 Boa noite a todos

 Estou instalando o postgres através do innosetup, utilizando a linha abaixo.
 A questão é que dessa forma não há uma verificação prévia de instalação
 anterior. Haveria algum parâmetro para checar se já existe uma versão do
 postgres instalada, e se ela é mais antiga que a versão que será instalada??

Não, não há. Para ver as opções disponíveis no instalador digite no console:

postgresql-9.3.2-1-windows.exe --help

 postgresql-9.3.2-1-windows.exe; Parameters: --serverport 5432 --locale C
 --superaccount postgres --superpassword root --unattendedmodeui minimal
 --debuglevel 2 --mode unattended; StatusMsg: Aguarde o final da
 instalação...;

Você terá que criar um programa que reconheça o conteúdo de um arquivo
texto gerado pelo comando:

psql -V  nome_do_arquivo.txt

Lembrando que mesmo assim, se você tiver uma versão mais antiga (i.e.
9.1 ou 9.2) simplesmente instalar a versão mais nova não irá atualizar
os bancos de dados. Será necessário fazer um dump [1] no cluster
antigo e depois recriar os bancos no cluster novo ou usar o utilitário
pg_upgrade [2] quando for possível.

[1] http://www.postgresql.org/docs/9.3/static/upgrading.html
[2] http://www.postgresql.org/docs/9.3/static/pgupgrade.html


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
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 postgres em windows

[Tiago José Adami]

Em 15 de maio de 2015 11:28, Guimarães Faria Corcete DUTRA, Leandro
l...@dutras.org escreveu:
 Em 15 de maio de 2015 11:25, Danilo Silva danilo.dsg.go...@gmail.com 
 escreveu:
 An error ocoured executing the Microsoft VC++ runtime installer

 Que tal instalá-lo à parte, então?

Peguei este erro outro dia no meu notebook com o último instalador da
versão 9.4.1-3. O motivo era um problema nas variáveis %TMP% e %TEMP%
do Windows que estavam apontando para um caminho inexistente.

Crie uma pasta, tipo C:\tmp e mude as variáveis TEMP e TMP do seu
usuário e do Windows para esta pasta. Você faz isso através do Painel
de Controle, Sistema e Segurança, Sistema, Configurações Avançadas do
Sistema, aba Avançado, botão Variáveis de Ambiente.

Lá você verá duas listas com variáveis. Altere a TEMP e TMP nas duas
caixas (são 4 variáveis) para este caminho C:\tmp e reinicie o
computador antes de tentar instalar outra vez.

Se não funcionar, tente fazer o download e instalar manualmente do
link [1]. Se ocorrer algum erro, ele irá gerar um arquivo de log e
provavelmente dirá onde fica este arquivo com informações importantes.

NOTA: Sempre que for instalar um programa no Windows utilize um
usuário com direitos de administrador.

[1] http://www.microsoft.com/en-us/download/details.aspx?id=46881



TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Fazendo insert massivo

[Tiago José Adami]

Em 12 de maio de 2015 16:45, Fernando Foster ferfos...@gmail.com escreveu:
 Olá pessoal, boa tarde.

 Sou iniciante no PostgreSQL (usamos faz 1 ano e meio) e estou com algumas
 duvidas.
 Tenho um projeto usando PostgreSQL onde faço estudos de vendas de lojas.
 Este servidor é uma instancia RDS da Amazon, pela questão de custos estamos
 mudando para o EC2. Como atendo cliente de vários tamanhos diferentes recebo
 mensalmente cargas de arquivos txt e xml com os dados das vendas, e em
 alguns caso o volume de informação é tão grande que ultrapassa 50.000 linhas
 por loja.

Em relação ao PostgreSQL esta quantidade é pequena.

 O numero de clientes que me envia informação chega próximo a 500,
 porém existe um plano para 1200 lojas em alguns meses.

50.000 x 1.200 = 600.000/mês -- Ainda é pouco para o PostgreSQL.

 Existe também um
 plano de trabalhar com informações mais detalhadas aumentando o tamanho em
 20 vezes.

Mesmo assim o postgres dá conta tranquilamente.

 A primeira questão, qual o jeito mais prático de fazer esses inserts?
 * Hoje fazemos o envio por uma espécie de streaming enviando pacotes de
 mil em mil linhas para nossa base.

Hoje você manda os inserts diretamente de uma máquina em algum ponto
do planeta para o servidor na nuvem, é isto?

Uma estratégia melhor é compactar o arquivo e enviá-lo ao servidor, e
lá descompactá-lo e realizar a inserção de dados através do comando
COPY [1] (como não foi informada a versão, citei a última: 9.4). Da
forma atual você está consumindo banda desnecessariamente.

 A segunda questão, além de receber os dados, fazemos cruzamentos e
 manipulações e por fim geramos dados consolidados, que transformam essas
 50.000 linhas em 200 linhas. Utilizar um servidor local para fazer esse
 processo seria uma boa jogada? Como fazer esse envio de dados para a base
 sem afetar a experiencia do cliente que está fazendo leitura desses dados?

Com certeza, se você pode mandar 200 ao invés de 50.000 é uma boa
estratégia (menor o tamanho de transferência). Considere mesmo assim
enviar o arquivo compactado para o servidor e descompactá-lo lá
dentro. Eu não sei como funciona o seu banco de dados na nuvem (nunca
usei RDS ou EC2) mas se você possui acesso a alguma parte do storage
via webservice ou SSH a melhor alternativa é tratar o insert
localmente na nuvem.

Caso não tenha esta possibilidade, dependendo das restrições de
segurança do PostgreSQL talvez seja possível criar uma função no banco
que receba este arquivo compactado e faça os tratamentos necessários
utilizando alguma outra linguagem (plpython, por exemplo). O pessoal
mais experiente da lista poderá dizer se é possível ou não (eu já vi
algo parecido mas não tenho fontes para citar, então dependo da ajuda
dos mestres desta lista).

[1] http://www.postgresql.org/docs/9.4/static/sql-copy.html

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Entre 1.000 a 10.000 bancos de dados PostgreSQL

[Tiago José Adami]

Em 10 de abril de 2015 16:36, Euler Taveira eu...@timbira.com.br escreveu:
 On 10-04-2015 11:37, Tiago José Adami wrote:
 Em 9 de abril de 2015 20:16, Euler Taveira eu...@timbira.com.br escreveu:
 Como eu já disse, a principal preocupação vai ser suportar uma
 quantidade grande de conexões. Os sistemas operacionais não lidam muito
 bem com dezenas de milhares de processos; mesmo em um servidor grande.
 Lembre-se, dividir para conquistar.

Estamos pensando em criar deploy automatico de VM's prontas e
individuais para cada cliente com acesso direto à storage (não usar
disco virtual). Como implementar isto já foge do escopo da lista,
então fico grato pelas respostas até o momento.

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] query com limit muito mais lenta

[Tiago José Adami]

2015-04-07 10:21 GMT-03:00 Alessandro Lima grandegoia...@gmail.com:
Cadê a consulta?

 SELECT prospects.nome AS nomeProspect, prospects.codigo AS codigoProspect,
 prospects.dataCadastro AS dataCadastro, prospects.telefoneResidencial AS
 telRes, prospects.telefoneComercial AS telComer, prospects.celular AS cel,
 prospects.telefoneRecado AS telRec, prospects.emailPrincipal AS email,
 interacaoworkflow.datainicio AS dataContato, interacaoworkflow.observacao AS
 observacao, situacaoprospectpipeline.controle AS
 controleSituacaoProspectPipeline, turma.identificadorturma AS turma,
 curso.nome AS nomeCurso, curso.codigo AS codigoCurso, consultorPadrao.nome
 AS nomeConsultorPadrao, pessoaResponsavel.nome AS nomeResponsavel,
 matricula.matricula, c3.nome AS cursoMatriculado, ( SELECT count (
 matricula.matricula ) FROM matricula WHERE aluno = pessoaProspect.codigo AND
 matricula.situacao = 'AT' )  0 AS possuiMatricula
  FROM prospects
  LEFT JOIN pessoa AS pessoaProspect ON pessoaProspect.codigo =
 prospects.pessoa
  LEFT JOIN interacaoworkflow ON interacaoworkflow.codigo = ( SELECT
 iwf.codigo FROM interacaoworkflow iwf WHERE prospects.codigo = iwf.prospect
 ORDER BY datainicio DESC LIMIT 1 )

 (corte)

Antes de continuar, todos estes LEFT JOINs estão certos? A intenção é
usá-los mesmo?

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] query com limit muito mais lenta

[Tiago José Adami]

Em 7 de abril de 2015 11:14, Alessandro Lima grandegoia...@gmail.com escreveu:
Antes de continuar, todos estes LEFT JOINs estão certos? A intenção é
 usá-los mesmo?
 Sim, a intenção é essa.

Você está buscando em algumas tabelas o registro mais recente de cada
prospect (como na tabela interacaoworkflow).
Estas tabelas se beneficiariam muito de um índice composto contendo o
campo data e o id/codigo nesta sequencia exata, melhorando a
seletividade.

Exemplo: CREATE INDEX ie_datainicio_prospect ON interacaoworkflow
(datainicio DESC, prospect)

Sobre a consulta, eu reescreveria a query deixando os relacionamentos
limpos nos LEFT JOINS e colocaria a condição para buscar o registro
mais atual de todas as tabelas no WHERE do SELECT principal, como no
exemplo:


Trocando isto:

FROM prospects
LEFT JOIN pessoa AS pessoaProspect
ON pessoaProspect.codigo = prospects.pessoa
LEFT JOIN interacaoworkflow ON
interacaoworkflow.codigo = (
SELECT
iwf.codigo
FROM
interacaoworkflow iwf
WHERE
prospects.codigo = iwf.prospect
ORDER BY
datainicio
DESC LIMIT 1
)



Por isto:

FROM prospects
LEFT JOIN pessoa AS pessoaProspect
ON pessoaProspect.codigo = prospects.pessoa
LEFT JOIN interacaoworkflow ON
interacaoworkflow.prospect = prospects.codigo

...

WHERE
(
interacaoworkflow.datainicio =
(
SELECT
MAX(iwf.datainicio)
FROM
interacaoworkflow iwf
WHERE
prospects.codigo = iwf.prospect
ORDER BY
iwf.datainicio DESC
)
)


Alterando também para a tabela cursointeresse e demais que fazem a
seleção pelo registro mais atual.


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
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 de Conexão !

[Tiago José Adami]

Em 6 de abril de 2015 15:39, Fabrízio de Royes Mello
fabri...@timbira.com.br escreveu:
 On 06-04-2015 12:50, Franklin Anderson de Oliveira Souza wrote:
 LOG: unexpected EOF on client connection with an open transaction

 Essas mensagens indicam que foi iniciada uma transação no PostgreSQL,
 porém o client (sua aplicação) terminou inesperadamente (alguem desligou
 a máquina/servidor ou até mesmo interrompeu a conexao de rede) antes de
 finalizar a sessão.


Aqui na lista este erro já apareceu várias vezes. Eu mesmo já passei
por isso em 2013 e você não irá acreditar no motivo [1]. Era uma
catraca que emitia um pulso na rede e fazia com que o banco de dados
encerrasse as conexões ativas em computadores distantes, mas na mesma
rede.

Faça testes com a máquina desconectada da rede ou em outra rede
isolada, lembrando de trocar switch, cabo, placa de rede, etc.

[1] 
https://listas.postgresql.org.br/pipermail/pgbr-geral/2013-September/036324.html

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
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 Embarcado- Existe?

[Tiago José Adami]

Em 6 de abril de 2015 15:36, Euler Taveira eu...@timbira.com.br escreveu:
 On 06-04-2015 14:34, Marcelo Silva wrote:
 Pessoal, existe postgres embarcado?

 Não. E nem vai existir.

 Ou uma versão de instalação sem intervenção do usuario, mas levando em conta 
 que já pode existir postgres na máquina.

 Isso pode ser feito. Se existir o postgres, o que quer fazer? Aconselho
 instalar em um diretório e porta personalizados.

 Gostaria de distribuir algumas aplicações simples, porem com um banco de 
 dados robusto.

 Pensei em usar o SQLite só pra localhost, mas como uso Posgres nas minhas 
 aplicações em rede, gostaria de manter o padrão.

 Se a aplicação é simples, eu iria de SQLite mesmo. Para que complicar se
 podemos simplificar?

+1

Aproveito para dar meu testemunho a respeito.

Já participei de um projeto de PoS com PostgreSQL embarcado e até hoje
é uma dor de cabeça enorme para a softhouse que o fez. Mas o motivo
não é o banco de dados, e sim, a péssima qualidade das máquinas que os
clientes têm, muitas vezes rodando Windows pirata sem contenção de
energia elétrica ou qualquer tipo de power surge. Frequentemente os
bancos de dados ficam corrompidos.

Eu já usei SQLite embarcado com um driver ODBC e minha única
reclamação dele é que ele é quase um arquivo texto sem muitas
restrições (você pode inserir texto em um campo tipo DATE, por
exemplo). Mas fora isso, ele é fantástico (rápido, portável, sem
frescura e muito melhor que um simples arquivo texto ou XML).

Se desejar algo mais robusto, tente o Firebird. Não sei como é hoje,
mas já vi softwares que o utilizam de forma embarcada com excelência.
Deixe o PostgreSQL no servidor, apenas - e usando Linux,
preferencialmente.


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Pool Jboos + PostgreSQL

[Tiago José Adami]

Em 6 de abril de 2015 14:33, Cleiton Luiz Domazak
cleitondoma...@gmail.com escreveu:
 Seguinte, hoje de manhã haviam algumas conexões em IDLE que monitoramos e se
 preciso matamos. Porém hoje logo após esta rotina de matar as conexões IDLE,
 os servidores de Aplicação simplesmente enlouqueceram abrindo centenas de
 conexões e quase travando o banco.

Reveja o limite mínimo e máximo de conexões e também o increment size.
Se você utiliza uma factory para criar as conexões considere a
possibilidade de criar uma entrada no log para cada vez que o método
que cria/usa uma conexão do pool é chamado. Seja no Jboss, Glassfish
ou mesmo em Tomcat utilizando C3P0, nunca vi algo parecido de conexões
serem criadas sem que a própria aplicação fizesse a demanda.

Pela descrição do teu problema, matar as conexões poderia fazer com
que o pool entendesse que elas ainda estavam ativas travando assim
toda a aplicação, e não o contrário. Já travei alguns Apps desta forma
- demorando um pouco até o pool identificar que as conexões realmente
haviam sido encerradas :)


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Database Soup: Primary Keyvil, reprised

[Tiago José Adami]

2015-03-31 20:50 GMT-03:00 Leandro Guimarães Faria Corcete DUTRA 
l...@dutras.org:
 http://www.databasesoup.com/2015/03/primary-keyvil-reprised.html


Mutability
The natural keys in my table can change, and IDs aren't allowed to change.

Desde os bancos da faculdade até todas as empresas e projetos que
trabalhei esta foi o principal (quando não o único) argumento: o que
fazer quando os campos da PK são alterados? Entretanto, o real motivo
era que em 100% dos casos o modelo era developer friendly voltado
para alguma ferramenta ou framework que se beneficia das surrogate
keys (Hibernate, Django, etc).

Confesso que levei pau muito tempo para conseguir fazer um esquema
limpo usando chaves naturais, e, até hoje me questiono se faço da
melhor forma possível. Principalmente porque nunca vi um esquema
projetado sem usar exclusivamente chaves primárias artificiais do tipo
ID autoincremento. Alguém conhece algum

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Verificar tabelas que precisam de VACUUM

[Tiago José Adami]

Trabalho com um determinado banco de dados para um aplicativo
científico com dados sensoriais (não sei como ele funciona, só cuido
das informações no SGBD) que possui acesso constante a algumas tabelas
24x7. O autovacuum parece não estar encontrando uma janela disponível
(o espaço utilizado em disco diminui
pouco ou nada comparado a um VACUUM explícito), então me obrigo a
colocar um agendamento no cron toda madrugada, deixando o banco
temporariamente inoperante.

Há como saber se o autovacuum está sendo eficiente? Tipo: um SELECT
que mostre quais tabelas precisam de VACUUM?

Dessa forma eu faria uma checagem e executaria somente quando necessário.

PostgreSQL 9.3.5.


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Verificar tabelas que precisam de VACUUM

[Tiago José Adami]

Em 23 de março de 2015 16:27, Matheus de Oliveira
matioli.math...@gmail.com escreveu:

 2015-03-23 16:13 GMT-03:00 Tiago José Adami adam...@gmail.com:
 Um VACUUM convencional não diminui o tamanho dos arquivos (de fato diminui
 em situações muito específicas, mas podemos dizer que isso é irrelevante no
 momento). Além disso, o VACUUM *não deixa o banco inoperante*. Já o VACUUM
 FULL faz as duas coisas: (1) diminui o tamanho dos arquivos, se possível, e
 (2) realiza um bloqueio das tabelas enquanto as processa.

 Logo, você está executando um VACUUM FULL? Se sim, isso pode ser uma prática
 bem ruim, o ideal é tentar otimizar o autovacuum para que este dê conta do
 recado.

Esqueci de mencionar, é um vacuumdb -v -f -z (ignorando os outros
parâmetros de conexão). Algumas tabelas recebem vários registros que
ao longo da semana são alterados e outra parte eliminados (uma delas
tem cerca de 500 mil registros novos por dia, ao final da semana a
tabela conta com 2 milhões de registros a mais). Só que varia muito de
tabela para tabela, conforme o tipo dos dados que são recebidos.

Sem o VACUMM FULL o tamanho do banco cresce vertiginosamente (em
disco), pois o banco de dados contém mais de 30 tabelas com mais de 60
colunas de diversos tipos.

 Veja a tabela pg_stat_all_tables (e pg_stat_user_tables) [1], as colunas
 n_live_tup e n_dead_tup podem ser usadas (e de fato é o que o autovacuum
 usa). Você também pode usar as consultas para fazer uma análise do inchaço
 de tabelas [2] e índices [3].

 [1]
 http://www.postgresql.org/docs/current/static/monitoring-stats.html#PG-STAT-ALL-TABLES-VIEW
 [2] https://wiki.postgresql.org/wiki/Show_database_bloat
 [3]
 http://blog.ioguix.net/postgresql/2014/03/28/Playing-with-indexes-and-better-bloat-estimate.html

A princípio, nunca me incomodei com isso antes. O autovacuum sempre
atendeu muito bem as minhas necessidades, principalmente a partir da
versão 9.1. Mas nesse caso vou criar um script para saber qual tabela
precisa de manutenção.

Agradeço pelas respostas (Matheus e Rafael).


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Em quanto tempo é o recomendável para executar um vacumdb e um analyze, pra deixar agendado na cron ?

[Tiago José Adami]

Em 23 de março de 2015 10:45, Matheus de Oliveira
matioli.math...@gmail.com escreveu:

 2015-03-20 18:10 GMT-03:00 Tiago José Adami adam...@gmail.com:

 Aproveitando o gancho


 Por favor, não sequestre uma thread, inicie uma nova conversar com sua
 dúvida, ok?

Desculpe, Matheus, mas acredito que minha questão está relacionada ao
OP, principalmente após sua resposta. Mas segui sua recomendação e
abri outra thread.

TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Em quanto tempo é o recomendável para executar um vacumdb e um analyze, pra deixar agendado na cron ?

[Tiago José Adami]

Em 20 de março de 2015 09:47, Matheus de Oliveira
matioli.math...@gmail.com escreveu:
 Nossa. Um e-mail sem corpo, pode isso Arnaldo?

 De qualquer forma, na maioria dos ambientes, e em versões mais recentes o
 autovacuum toma conta disso tudo com sucesso. Em alguns ambientes, após uma
 análise mais detalhada nós fazemos o agendamento, mas geralmente é para um
 conjunto específico de tabelas.

 Se quiser agendar um VACUUM ANALYZE em horários de menor atividade do
 sistema, não vai fazer mal (veja o tempo que demora e garanta que não
 intercala com uso mais ativo do sistema). Só não caia na armadilha de
 agendar um VACUUM FULL, nem REINDEX. Só os faça se realmente comprovar a
 necessidade.

 Outro ponto é fazer um VACUUM ANALYZE de tabelas após carga de dados grandes
 ou operações de UPDATE/DELETE em batch, ou ainda após uma restauração. Mas
 veja que não é agendado, é algo que faz parte da operação, e mais uma vez, é
 preciso uma análise, nem sempre é necessário.


Aproveitando o gancho: trabalho com um determinado banco de dados para
um aplicativo científico com dados sensoriais (não sei como ele
funciona, só cuido das informações no SGBD) que possui acesso
constante a algumas tabelas 24x7. O autovacuum parece não estar
encontrando uma janela disponível (o espaço utilizado em disco diminui
pouco ou nada comparado a um VACUUM explícito), então me obrigo a
colocar um agendamento no cron toda madrugada, deixando o banco
temporariamente inoperante.

Há como saber se o autovacuum está sendo eficiente? Tipo: um SELECT
que mostre quais tabelas precisam de VACUUM?

Dessa forma eu faria uma checagem e executaria somente quando necessário.

PostgreSQL 9.3.5.


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Quando conectar ao banco ?

[Tiago José Adami]

Em 5 de novembro de 2014 14:37, Eduardo Bohrer nblui...@gmail.com escreveu:
 2014-11-05 14:24 GMT-02:00 Marco Aurelio marcoprod...@gmail.com:

 Caros,

 Estou desenvolvendo um sistema em java com JDBC e surgiu uma dúvida
 básica.
 O melhor para o banco é:
 1) Conectar a cada comando que for ser executado, e em seguida fechar a
 conexão.
 2) Conectar ao iniciar a aplicação, e apenas testar se a mesma não caiu
 quando precisar executar um comando, e deixar a conexão aberta até o
 encerramento da aplicação.


 Depende um pouco de comportamento da aplicação.

 Se será algo que vai executar com um espaço grande de tempo. Abrir e fechar
 a cada processo pode valer mais a pena por não manter conexões
 desnecessárias ao banco.

 Se esta conexão será aberta o tempo todo, o mais comum é mante-la aberta
 mesmo.
 Normalmente utilizamos pools de conexão para resolver este tipo de problema.
 Eles inclusive já fazem o trabalho chato de testar conexões e reabrir caso
 seja necessário, além de outras features interessantes.
 Para java o mais conhecido acredito que seja o c3p0 [1].

 [1] http://www.mchange.com/projects/c3p0/


+1

C3P0 é muito simples de usar e funciona muito bem com PostgreSQL.


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] É melhor uma trigger para várias operações, ou uma para cada operação?

[Tiago José Adami]

Em 1 de outubro de 2014 15:32, Targino Silveira
targinosilve...@gmail.com escreveu:
 Senhores,

 Estou fazendo algumas alterações num banco de dados, e vou precisar criar
 triggers para inserts, updates e deletes, e acabei me pegando com a seguinte
 questão.

 O que é mais performatico, uma trigger para insert, outra para update e
 outra para delete ou apenas uma com a condicional que verifica quais das
 três operações esta ocorrendo e realize a execução do código correspondente?

 Eu vejo que triggers separadas da uma melhor manutenção do código, fica mais
 intuitivo e trechos menores de código são executados de forma mais rápida do
 que trechos maiores.

 O vocês o que me dizem? Já fizeram algum benchmark desse tipo?

Já desmembrei o código de uma função de TRIGGER em 3 distintas, uma
para cada operação e não percebi perdas ou ganhos (a função original
era gigantesca e de difícil manutenção). Talvez se você tiver um
número exagerado de TRIGGERs faça alguma diferença, mas pelas
experiências que eu tive, não existem alterações significativas.

O que acha de fazer os testes e postar aqui os resultados?

--
TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] sql - como montar uma view para tabela de historico

[Tiago José Adami]

Em 27 de setembro de 2014 00:42, Paulo Vitor Bettini de Albuqerque
Lima paulovitor...@gmail.com escreveu:
 Eu sei como criar uma view. Eu só não gostei da minha solução com
 subqueries. Explicando um pouco melhor o problema. Esse cenário se repete 4
 vezes. Tenho 4 tabelas de pareceres cada uma salvando histórico de um tipo
 de unidades. Eu não posso colocar aqui os nomes reais das tabelas por conta
 de um tratado de confidencialidade.

 Eu quero evitar ao máximo criar uma view com 4 unions e cheia de subqueries.
 Por isso recorri aos gurus da lista.

Está difícil entender o seu modelo sem a representação de FK's ou pelo
menos uma designação de como as tabelas se relacionam. De qualquer
forma, como você mesmo disse que o sistema é mal-feito, é praticamente
impossível dar alguma opinião sem saber a quantidade de registros,
índices existentes, relacionamentos lógicos (mesmo que sem FK) e o
código SQL que você propõe.

Poste o código da VIEW e troque os nomes de tabelas e atributos para
que seja possível opinarmos.

--
TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] duvida com indice em campo booleano

[Tiago José Adami]

Em 19 de setembro de 2014 23:28, Wellington wm...@yahoo.com.br escreveu:
 Pessoal,

 em uma tabela foi criado um indice assim: campo = false.

 Quando eu rodo a consulta selecionando campo is false, o indice nao é
 utilizado.
 O indice so é utilizado se seleciono campo = false.
 Alguem saberia me explicar por que isso acontece ?

Esse é um recurso do PostgreSQL chamado índice parcial (ou /partial
index/ [1]). Se for utilizar esse recurso, você precisaria criar um
índices para os valores false e outro para os valores true. Dependendo
do número de registros da tabela, um índice simples (sem a clausula de
condição explícita) já é o bastante.

Resumindo: ao invés de criar o índice com uma condição (coluna =
valor), utilize apenas o nome da coluna.

CREATE INDEX indice ON tabela (nome_da_coluna)

Dá uma lida na documentação abaixo:

[1] http://www.postgresql.org/docs/9.3/static/indexes-expressional.html


TIAGO J. ADAMI
http://www.adamiworks.com
@tiadami
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral