CHAVE PRIMARIA OCULTA?
Aproveitando a deixa desse tópico......
Matioli....
A algum tempo atraz....vi algo assim.....
0013200060599 onde com a mascara ficava assim :
001.320.006.05-99 - essa sequencia identificava uma consultora de belza...(AVOM/NATURA/PAYOT) ONDE :
001 = SUPERVISOR
320 = CIDADE
006 = BAIRRO
05 = SETOR ' TAMBEM CONHECIDO COMO RUA
99 = CONSULTORA.
talvez sirva como critério ae para a codificação do seu projeto....
ta ai minha sugestão....
Matioli....
A algum tempo atraz....vi algo assim.....
0013200060599 onde com a mascara ficava assim :
001.320.006.05-99 - essa sequencia identificava uma consultora de belza...(AVOM/NATURA/PAYOT) ONDE :
001 = SUPERVISOR
320 = CIDADE
006 = BAIRRO
05 = SETOR ' TAMBEM CONHECIDO COMO RUA
99 = CONSULTORA.
talvez sirva como critério ae para a codificação do seu projeto....
ta ai minha sugestão....
Código aleatório nao funciona, pelos motivos que o MATIOLI citou, acredito que usar uma chave SHA ou MD5, a partir do nome do cliente somado a data de cadastro, ou ao CNPJ, ou CPF, ou outro parà ¢metro pode é bem melhor, aconselho utilizar chave com 8 ou 10 dÃgitos, o que evita a duplicação mesmo.
Quanto a velocidade de acesso e busca, não acho que comprometa se o campo for texto e limitado a um tamanho pequeno.
Bom tenho uma bas e de dados com aproximadamente 2500 cadastros (sei que é pequeno) e nele consigo localizar rapidamente o código (menos de 1 seg.), com chave de ID com 25 dÃgitos. Assim a velocidade vai estar ligada mais a configuração da máquina, da velocidade da rede, númeor de usuário conectados a base de dados, do que com o tamanho do campo.
Quanto a velocidade de acesso e busca, não acho que comprometa se o campo for texto e limitado a um tamanho pequeno.
Bom tenho uma bas e de dados com aproximadamente 2500 cadastros (sei que é pequeno) e nele consigo localizar rapidamente o código (menos de 1 seg.), com chave de ID com 25 dÃgitos. Assim a velocidade vai estar ligada mais a configuração da máquina, da velocidade da rede, númeor de usuário conectados a base de dados, do que com o tamanho do campo.
Olha um exemplo de ID de uma das tabelas:
A3A36E9(.S3_#S*
9ZWOGL1&!72{?T:
9ZWPAI3()%1D?T:
9ZX72W5$@KL#?T:
A2U345N*V$2:.A5
9YULEUX%-83^),-
BBXJYX2)A2K']GJ
A3A36E9(.S3_#S*
9ZWOGL1&!72{?T:
9ZWPAI3()%1D?T:
9ZX72W5$@KL#?T:
A2U345N*V$2:.A5
9YULEUX%-83^),-
BBXJYX2)A2K']GJ
MARCOS sei não, mas isso tá com cara de estar criptografado, provavelmente ele forma o ID como o FOXMAN e o WCOSTA disse e criptografa isso tb...
Mas colega, dependendo do sistema, vc não precisa se preocupar com isso, na maioria acredito que uma autonumeração comum seja a melhor escolha, claro que há excessões como o de LOCADORA que eu falei e este citado pelo FOXMAN...flw
Mas colega, dependendo do sistema, vc não precisa se preocupar com isso, na maioria acredito que uma autonumeração comum seja a melhor escolha, claro que há excessões como o de LOCADORA que eu falei e este citado pelo FOXMAN...flw
Grego
Sim, uma chave primária com inteiro é muito mais eficiente que uma String, pelo simples fato de que um relacionamento extenso, 10 tabelas por exemplo, pode tornar alguns processos extremamente lentos.
Um exemplo, um Sistema que utilizava massivamente Strings foi migrado para 80% de números inteiros ou longos, e uma rotina de extração de dados obteve uma redução de 1 hora para 30 segundos.
A Modelagem neste caso também auxiliou mas os Ãndices com certeza também, chaves tipo Integer são 40 vezes mais rápidas em indÃces que Strings, se eu não me engano.
Até Breve
Sim, uma chave primária com inteiro é muito mais eficiente que uma String, pelo simples fato de que um relacionamento extenso, 10 tabelas por exemplo, pode tornar alguns processos extremamente lentos.
Um exemplo, um Sistema que utilizava massivamente Strings foi migrado para 80% de números inteiros ou longos, e uma rotina de extração de dados obteve uma redução de 1 hora para 30 segundos.
A Modelagem neste caso também auxiliou mas os Ãndices com certeza também, chaves tipo Integer são 40 vezes mais rápidas em indÃces que Strings, se eu não me engano.
Até Breve
Não faz muito sentido criptografar o ID... não é mesmo?
Alem do mais, o sistema nem é meu.
Alem do mais, o sistema nem é meu.
WCosta
Localizar eu acredito que não seja o problema, ele irá localizar em milisegundos, o problema está na extração de dados, na hora de tomada de decisão, com Chaves Strings o processo se torna lento em escala, quanto mais chaves strings em relacionamentos mais demorada a resposta do Engine da Base e se a quantidade de tabelas for extensão e a quantidade de dados, geralmente um perÃodo de tempo, for de uma amplitude relativamente grande, pode-se ir tomar uma cafezinho, almoçar, etc....
Isto eu já presenciei na prática, com modelagem herdada e outra atualizada.
Até Breve
Localizar eu acredito que não seja o problema, ele irá localizar em milisegundos, o problema está na extração de dados, na hora de tomada de decisão, com Chaves Strings o processo se torna lento em escala, quanto mais chaves strings em relacionamentos mais demorada a resposta do Engine da Base e se a quantidade de tabelas for extensão e a quantidade de dados, geralmente um perÃodo de tempo, for de uma amplitude relativamente grande, pode-se ir tomar uma cafezinho, almoçar, etc....
Isto eu já presenciei na prática, com modelagem herdada e outra atualizada.
Até Breve
Citação:MARCOS LING escreveu:
Não faz muito sentido criptografar o ID... não é mesmo?
Alem do mais, o sistema nem é meu.
Realmente não faz, mas é que achei estes números aà fora do nÃvel considerado de estranhesa (
), realmente parece dados criptografados, tem certeza q isso são os IDs?
Certeza absoluta!
Caro colega então veja o seguinte , se está maravilhado com os softwares que andam por ai entao dê uma olhada em : http://www.vbmania.com.br/vbmania/vbmdetail.php?varID=3753
Tópico encerrado , respostas não são mais permitidas