Em 19 de julho de 2011 22:26, Euler Taveira de Oliveira <[email protected]>escreveu:
> 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. > > Lembre-se que "João da Silva + CPF" pode fazer mais de 1 pedido, então teria de ter mais um atributo para garantir a unicidade... > 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). > > Também concordo com todo exposto, entretanto existem casos em que a Numeração Sequencial (sem falhas) é exigência legal... trabalho com software de gestão para Órgãos Públicos e os mesmos emitem os chamados "Empenhos" para executar a despesa (pagar fornecedores, pessoal, etc)... é como uma Nota Fiscal na iniciativa privada... e estes NÃO podem ter falhas na sua numeração sequencial, senão a auditoria dos estados (TCEs) apontam esse tipo de irregularidade. Esse é só um exemplo em que não podem existir falhas em numerações, e existem outros casos. -- Fabrízio de Royes Mello >> Blog sobre TI: http://fabriziomello.blogspot.com >> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
