Não tinha parado para analisar a capacidade do bigint. Boa observação,
talvez eu não precise fazer nada então pois a média de novos registros é de
100 por dia.
Em 24 de março de 2015 17:08, Matheus de Oliveira escreveu:
>
> 2015-03-24 17:05 GMT-03:00 Matheus de Oliveira
> :
>
>> Agora, se consi
2015-03-24 12:34 GMT-03:00 Zan :
> Me lembrei agora que este é o horário de backup da base. Pode ser isso?
Se for um backup pg_dump, com certeza. O pg_dump requer bloqueio usando um
AccessShareLock, o que conflita com o AccessExclusiveLock (na verdade
qualquer um conflita com esse último), reque
2015-03-24 12:31 GMT-03:00 Zan :
> ALTER TABLE portal.tb_tarefa
> ADD COLUMN id_usuario INTEGER;
>
> Esta é uma tabela pequena, com 200 registros, mas o comando não executa.
> Já percebi que algumas vezes quando faço um select em uma tabela com
> transação ativa a tabela fica em "Lock", não deix
2015-03-24 17:05 GMT-03:00 Matheus de Oliveira :
> Agora, se considerássemos 1000 linhas por segundo, com integer aguentaria
> apenas 24 dias, já bigint aguentaria 292 bilhões de anos.
Corrigindo, seria 292 milhões...
Atenciosamente,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sis
2015-03-24 10:38 GMT-03:00 Matheus Saraiva :
> No meu ponto de vista bigint e bigserial são necessários quando, por
> exemplo, temos uma chave artificial que pode crescer de forma mais
> rápida que o normal.
> Além desse caso, quais seriam os outros casos em que eles são uteis?
>
>
Crescer de form
Em 24/03/15, Matheus Saraiva escreveu:
> No meu ponto de vista bigint e bigserial são necessários quando, por
> exemplo, temos uma chave artificial que pode crescer de forma mais
> rápida que o normal.
> Além desse caso, quais seriam os outros casos em que eles são uteis?
>
> Aproveitando esse tema
Nesse caso a ideia era reiniciar a sequence.
Os registros antigos eram movidos para outro repositório (poderia ser uma
tabela ou banco distinto, ou até outra tecnologia de armazenamento). A
aplicação teria que ser ajustada pra trabalhar desta forma.
Um problema é que todas as referências eram movi
2015-03-24 13:55 GMT-03:00 Matheus Silva :
> Desculpe Brother mas não concordo com você, não vou aqui entrar no mérito
> para não desviar o foco do email. Você pode apresentar as desvantagens da
> minha modelagem e eu posso enumerar as vantagens, bem como as desvantagens
> da sua proposta, convém a
Desculpe Brother mas não concordo com você, não vou aqui entrar no mérito para
não desviar o foco do email. Você pode apresentar as desvantagens da minha
modelagem e eu posso enumerar as vantagens, bem como as desvantagens da sua
proposta, convém a que preparou a modelagem pesar os prós e contra
2015-03-24 13:39 GMT-03:00 Matheus Silva :
> O email apesar de único não pode ser obrigatório.
Uma imagem nunca dará todas as informações, do tipo ‘por que não
pode?’. De qualquer maneira, parece um modelo muito ruim esse, mas
aqui não é o lugar para explorar todos os problemas potenciais.
Como
O email apesar de único não pode ser obrigatório.
Pessoalmente eu acho que não se pode generalizar tal coisa, cada caso é um caso.
A imagem mostra os campos necessário bem como as chaves unique e campos
obrigatórios.
-Mensagem Original-
De: "Guimarães Faria Corcete DUTRA, Leandro"
Enviad
2015-03-24 12:51 GMT-03:00 Matheus Saraiva :
>
> Qual a chave natural para a tabela "Pessoas" na imagem?
Imagem nunca tem todas as informações necessárias à modelagem. Uma
das razões para evitar modelagem por diagramas.
> A ideia da
> tabela pessoas é armazenar os dados de qualquer pessoa seja
Everton, qual a ação vocês realizariam quando estourar o limite?
-Mensagem Original-
De: "Everton Berz"
Enviada em: 24/03/2015 13:02
Para: "Comunidade PostgreSQL Brasileira"
Assunto: Re: [pgbr-geral] bigint e bigserial, quando usar?
Tenho um caso que usei bigserial, foi em uma tabela
Tenho um caso que usei bigserial, foi em uma tabela de log das operações
que os usuários realizavam no sistema. Calculamos que levaria alguns anos,
mas poderia acontecer, e quando acontecesse, pouparíamos trabalho dos
futuros dba's.
As colunas da tabela eram:
- id bigserial (chave artificial)
- da
Em Ter, 2015-03-24 às 12:39 -0300, Leandro Guimarães Faria Corcete DUTRA
escreveu:
> Le 24 mars 2015 12:36:45 GMT-03:00, Matheus Saraiva
> a écrit :
> >Em Ter, 2015-03-24 às 11:13 -0300, Guimarães Faria Corcete DUTRA,
> >Leandro escreveu:
> >
> >Correto, mas vale ressaltar que nem todas as tabela
On 24/03/2015 12:31, Zan wrote:
Versão: PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu, compiled by gcc
(Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit
Boa tarde.
Estou tentando fazer a seguinte alteração na estrutura de uma tabela:
ALTER TABLE portal.tb_tarefa
ADD COLUMN id_usuario INTEGER;
Est
Le 24 mars 2015 12:36:45 GMT-03:00, Matheus Saraiva
a écrit :
>Em Ter, 2015-03-24 às 11:13 -0300, Guimarães Faria Corcete DUTRA,
>Leandro escreveu:
>
>Correto, mas vale ressaltar que nem todas as tabelas tem algum campo
>que
>possa ser usado como chave natural.
Só por erro de modelagem, nem que
Em Ter, 2015-03-24 às 11:13 -0300, Guimarães Faria Corcete DUTRA,
Leandro escreveu:
> 2015-03-24 10:38 GMT-03:00 Matheus Saraiva :
> >
> > Aproveitando esse tema, alguém aqui na comunidade já atingiu o limite do
> > integer com chaves artificiais? O que acontece e o que fazer?
>
> Não é uma respos
Versão: PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu, compiled by gcc
(Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit
Boa tarde.
Estou tentando fazer a seguinte alteração na estrutura de uma tabela:
ALTER TABLE portal.tb_tarefa
ADD COLUMN id_usuario INTEGER;
Esta é uma tabela pequena, com 200 r
2015-03-24 10:38 GMT-03:00 Matheus Saraiva :
>
> Aproveitando esse tema, alguém aqui na comunidade já atingiu o limite do
> integer com chaves artificiais? O que acontece e o que fazer?
Não é uma resposta à tua pergunta, mas acabo de pensar que, com chaves
naturais, isso não aconteceria salvo erro
No meu ponto de vista bigint e bigserial são necessários quando, por
exemplo, temos uma chave artificial que pode crescer de forma mais
rápida que o normal.
Além desse caso, quais seriam os outros casos em que eles são uteis?
Aproveitando esse tema, alguém aqui na comunidade já atingiu o limite do
21 matches
Mail list logo
