Em 19-07-2011 17:49, Johnny Chaves escreveu:
> Em seg 11 jul 2011, às 17:50:24, Leandro DUTRA escreveu:
>> 2011/7/11 Alexsander Rosa<[email protected]>:
>>> As pessoas estão acostumadas a receber um "número de pedido" quando
>>> compram alguma coisa.
>
E por que não o pedido do João da Silva + CPF? Acho que seria muito mais
elegante o funcionário dizer: Seu João da Silva? Aqui está o seu pedido. Do
que: Número? 7..9..5..7..2..3..9..5..8..2..3..7. Aqui está o seu pedido.
> Parece que esse é o maior problema *cultural*, tive resistência nesse ponto,
> incluindo a tentativa de não deixar "buracos" na sequência, até que o Roberto
> Melo (Mello?), da antiga lista me questionou (e há vários outros ao mesmo
> tempo), o motivo ou vantagem dessa ação, não pude (pudemos) responder, e
> desisti da idéia de *fechar buracos* na sequência, mas continuo atrás do santo
> graal para PK em pessoas, que se propagaria em clientes, funcionários,
> fornecedores...
>
Eu me recordo de algumas discussões sobre *buracos* em sequência. O que as
pessoas não entendem é que a obtenção de um número da sequência *não* é
transacional, ou seja, não há como dar um rollback do número obtido se a
transação falhar. Muitas pessoas julgam que isso é um problema grave mas eu
argumento que há mais vantagens do que essa "desvantagem". Explico: para obter
uma sequência sem *buracos* teríamos que serializar as operações básicas do
SQL (INSERT, DELETE, UPDATE) e isso é um problema porque poderíamos ter uma
transação longa impedindo que outras transações menores terminem simplesmente
porque não há a certeza que a transação longa utilizará o próximo número da
sequência. Isso em si é uma desvantagem muito maior do que ter *buracos* em
uma sequência. Além disso, se você estiver tão preocupado assim em fechar os
buracos de uma sequência, você deve fazê-lo após o buraco aparecer; e, neste
caso, a própria aplicação deve gerenciar isso. IMHO, isso é muito trabalhoso e
não compensa fazer. A aplicação teria que fazer:
IF ha_buracos() THEN
INSERT com primeiro buraco
ELSE
INSERT com sequencia
END IF
De qualquer forma, isso não garante que nunca haverá buracos; haverá mas a
aplicação irá tampá-los ao longo do tempo.
Expor um número identificador que não faz muito sentido fora da aplicação é um
erro. Na verdade, esse identificador deveria ficar restrito ao modelo físico
do SGBD (argh, oids) mas não é o que ocorre na prática (a parcela de culpa
fica dividida entre o padrão SQL e o desenvolvedor).
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
