Em ter 19 jul 2011, às 22:26:23, Euler Taveira de Oliveira escreveu: > 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, obrigado, mas como disse, entendi e *desisti* de *tapar buracos*, não desisti ainda foi de encontrar chaves naturais para pessoas, principalmente físicas, ainda as uso, mas a contra gosto. ps:Não removi *nenhuma* parte da mensagem, por acreditar que o exposto relata a verdade, apesar de ainda (como as outras :( ), não apresentar a solução :( . -- Johnny Taylor Faria Chaves - LUN 157066 www.brdados.com.br - jfchaves <at> brdados.com.br Eu não posso mais, se você pode, doe sangue!!! _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
