Campo autoincremento no DbExpress Firebird. Opiniao
Olá pessoal,
Estou usando as tecnologias do FB e DbXpress, agora queria a opinião de vc´s em relação a um procedimento que estamos usando para fazer a autoincrementação.
Não usamos Stored Procedures nem Triggers no FireBird para fazer autoincremento, não usamos para manter compatibilidade com outros bancos caso futuramente queiramos mudar de banco.
Nós fazemos assim,
Criamos uma tabela apenas com os indices para as tabelas, e antes de inserir um registro nossa classe acessa essa tabela pega o valor atribui para chave primaria do novo registro e incrementa e valor e salva na tabela de de indices.
Fazemos isso sempre que há um novo registro.
O que vc´s usam e o que vc´s recomendam em relação a isso? Pode ficar lento, é trabalho jogado fora? Gostaria da opnião de vc´s.
Obrigado. :D
Yalle Cunha.
Estou usando as tecnologias do FB e DbXpress, agora queria a opinião de vc´s em relação a um procedimento que estamos usando para fazer a autoincrementação.
Não usamos Stored Procedures nem Triggers no FireBird para fazer autoincremento, não usamos para manter compatibilidade com outros bancos caso futuramente queiramos mudar de banco.
Nós fazemos assim,
Criamos uma tabela apenas com os indices para as tabelas, e antes de inserir um registro nossa classe acessa essa tabela pega o valor atribui para chave primaria do novo registro e incrementa e valor e salva na tabela de de indices.
Fazemos isso sempre que há um novo registro.
O que vc´s usam e o que vc´s recomendam em relação a isso? Pode ficar lento, é trabalho jogado fora? Gostaria da opnião de vc´s.
Obrigado. :D
Yalle Cunha.
Yallebr
Curtidas 0
Respostas
Vinicius2k
30/03/2005
Colega,
Penso que a diferença de performance seria mínima, mas a diferença na segurança seria muito grande...
Os generators são totalmente seguros quanto à duplicação, já o uso de uma tabela auxiliar é extremamente arriscado em ambientes client/server e quanto maior o número de usuários, maior o risco...
Utilizar generators com triggers é uma prática comum e segura, mas se mesmo assim vc não desejar utilizar as triggers, utilize apenas os generators e recupere o valor de autoincremento para o registro a ser inserido através de uma query :
Desta forma o retorno desta query será o seu valor a utilizar no registro e o generator será incrementado no banco de dados.
Isto é 100¬ seguro e, inclusive, está fora do contexto da transação. Ou seja, mesmo que uma transação seja desfeita, o generator não será afetado, tornando nula a possibilidade de duplicação de chave.
T+
Penso que a diferença de performance seria mínima, mas a diferença na segurança seria muito grande...
Os generators são totalmente seguros quanto à duplicação, já o uso de uma tabela auxiliar é extremamente arriscado em ambientes client/server e quanto maior o número de usuários, maior o risco...
Utilizar generators com triggers é uma prática comum e segura, mas se mesmo assim vc não desejar utilizar as triggers, utilize apenas os generators e recupere o valor de autoincremento para o registro a ser inserido através de uma query :
select GEN_ID(nome_do_generator, 1) from RDB$DATABASE
Desta forma o retorno desta query será o seu valor a utilizar no registro e o generator será incrementado no banco de dados.
Isto é 100¬ seguro e, inclusive, está fora do contexto da transação. Ou seja, mesmo que uma transação seja desfeita, o generator não será afetado, tornando nula a possibilidade de duplicação de chave.
T+
GOSTEI 0
Andremuller
30/03/2005
Se o número de pessoas for importante para você tomar a decisão quero dizer que concordo 100¬ e utilizo a mesma técnica postada pelo Vinicius2K
GOSTEI 0
Yallebr
30/03/2005
Pessoal,
Obrigado pela opinião.
Não consigo ver a questão sobre a segurança. Duplicação de registro que vc´s falaram. Ao meu ver os 2 casos são 100¬ livres desse problema.
Pois vejam bem.
Forma 1) Tabela auxiliar.
Passos.
1) Abri Edição para tabela. (Edit) Ou seja,
2) Bloqueio o registro para Leitura e gravação.
2) Li o valor.
3) Incrementei.
4) Salvei o registro com novo valor incrementado.
5) Libero a tabela para Leitura e gravação.
Caso não esteja errado, o banco irá bloquear o registro quando eu der uma edição nele. Nesse momento ninguem mais poderá ler registro até que eu incremente e salve ele. (Assim libero o registro).
O tempo para fazer isso é mínimo, então pode gerar um tempo de espera de milésimos de segundos.
A questão é que quero ficar livre do banco de dados. pois futuramente posso querer modifica-lo.
E ai, o q acham ? :P
Obrigado pela opinião.
Não consigo ver a questão sobre a segurança. Duplicação de registro que vc´s falaram. Ao meu ver os 2 casos são 100¬ livres desse problema.
Pois vejam bem.
Forma 1) Tabela auxiliar.
Passos.
1) Abri Edição para tabela. (Edit) Ou seja,
2) Bloqueio o registro para Leitura e gravação.
2) Li o valor.
3) Incrementei.
4) Salvei o registro com novo valor incrementado.
5) Libero a tabela para Leitura e gravação.
Caso não esteja errado, o banco irá bloquear o registro quando eu der uma edição nele. Nesse momento ninguem mais poderá ler registro até que eu incremente e salve ele. (Assim libero o registro).
O tempo para fazer isso é mínimo, então pode gerar um tempo de espera de milésimos de segundos.
A questão é que quero ficar livre do banco de dados. pois futuramente posso querer modifica-lo.
E ai, o q acham ? :P
GOSTEI 0
Vinicius2k
30/03/2005
Bem, agora já mudou (um pouco) a história já que vc está pensando em usar travamentos... Neste caso, ao menos à princípio, penso que o problema de duplicação estaria contornado, mas vc *pode* estar resolvendo um problema simples criando outro maior...
Note bem que um travamento de registro pode levar mais do que ´alguns milésimos de segundo´ para o último usuário da fila dependendo do número de usuários concorrentes na mesma tabela... Vc pode estar criando um ´gargalo´ na sua aplicação, dependendo das operações que ela for realizar, por isso sugiro cuidado.
Antes de partir para uma solução com travamento, sugiro que leia este artigo : http://www.comunidade-firebird.org/cflp/downloads/CFLP_T032.PDF
Ainda não entendi seu ponto de vista quanto a uma possível mudança de banco... É verdade que a solução de auto-incremento do IB/FB não é tão ´comum´, mas é tão segura quanto as colunas ´AutoInc´ da maioria dos SGBDs... Se vc resolver migrar de SGBD mais tarde, apenas abandone o uso dos generators e triggers de auto-incremento e use uma coluna AutoInc, Identity, etc...
O resultado será o mesmo : geração de IDs sequenciais seguras e 100¬ independentes da aplicação.
Bem, este é o meu ponto de vista.
T+
Note bem que um travamento de registro pode levar mais do que ´alguns milésimos de segundo´ para o último usuário da fila dependendo do número de usuários concorrentes na mesma tabela... Vc pode estar criando um ´gargalo´ na sua aplicação, dependendo das operações que ela for realizar, por isso sugiro cuidado.
Antes de partir para uma solução com travamento, sugiro que leia este artigo : http://www.comunidade-firebird.org/cflp/downloads/CFLP_T032.PDF
Ainda não entendi seu ponto de vista quanto a uma possível mudança de banco... É verdade que a solução de auto-incremento do IB/FB não é tão ´comum´, mas é tão segura quanto as colunas ´AutoInc´ da maioria dos SGBDs... Se vc resolver migrar de SGBD mais tarde, apenas abandone o uso dos generators e triggers de auto-incremento e use uma coluna AutoInc, Identity, etc...
O resultado será o mesmo : geração de IDs sequenciais seguras e 100¬ independentes da aplicação.
Bem, este é o meu ponto de vista.
T+
GOSTEI 0