• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

cheires

Iniciar uma primary key com outro valor

17 mensagens neste tópico

Olá pessoal, surgiu uma dúvida no mysql.

Queria iniciar uma primaru key com uma valor inteiro, mas tipo, em vez de começar em zero, começar por exemplo em 10.

Será possível fazer isso? Se é, como se faz?

Obrigado a todos.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Boax....

ALTER TABLE A_TUA_TABELA AUTO_INCREMENT=N

N-Valor inicial.

Nem vou perguntar em que situcao pretendes fazer isto....

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Mas eu respondo-te...

Como a tabela se refere a uma numeração existente, e pretendo continuar a numeração existente, se ter que começar uma nova numeração.

Obrigado pela ajuda  :(

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Se a tabela já existir.. seguia o exemplo acima.. por exemplo..

se fôr na altura de criação da tabela eu sugeria umas das seguintes opções...

chave int identity(10,1) primary key  

  basicamente começa no valor 10.. e vai incrementando de 1 ..

ou .... se não quiseres que seja auto increment...

chave int primary key default ( Select .... )

  naquele select ias percorrer a tabela k tens e punhas o ultimo valor existente mais 1 .. por exemplo...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

boax...

O meu comentário foi porque:

Para pedires isso quase de certeza que usas chaves naturais... acho que é assim que se chamam  :hmm:

Eu, como muitos outros, defendo que as chaves primárias nunca deveriam ser naturais, mas sim, numericas, sem qualquer relacao directa com os dados.. ou seja, nunca usar o numero da factura, o numero do B.I., numero de contribuinte,etc  ... para chave primaria.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

RVG, podias explicar porque defendes a não utilização do BI (ou outros) para chave primária?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Sim também gostava de ler essa explicação.

Sempre me ensinaram que as chaves primárias devem identificar o registo.

O num de BI é um identificador da tua pessoa.

Assim como o numero de factura, etc.

Não tem sentido pores 2 identificadores num mesmo registo. Se tens o num de factura, e se esse registo não pode ser mudado nem repetido, qual o mal em utiliza-lo?

Abraço

e obrigado pela sugestão

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Concordo como RVG. A teoria revela-se diferente da prática.

Se não queres ter futuros problemas o melhor é separar os dados referenciais da informação.

Aquilo que não é para alterar hoje pode não ser verdade daqui a 2 anos, nem que seja num ambito de suporte, numa eventual resolução de problemas.

O negocio muda mais rápido que o software.

Basta um pequeno exemplo:

Foram introduzidos dados de uma empresa, o NIF é usado com chave, a chave é referencia em várias tabelas.

Chegou-se a conclusão que se enganaram a inserir o NIF... pronto já está aqui uma carga de trabalho.

PS: Eu observo estes problemas todos os dias.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Mais um que defende o uso de chaves somente como chaves - eu.

Outro problema: por alguma razão apagas o ultimo registo porque nao foi bem inserido ou por outra razão... para inserir um registo com esse id tem que ser manualmente.

Ou seja... uma grande complicação.

Usar uma chave inteira auto.increment sem nenhum dado implicito, não invalida o uso de colunas em que todos os valores tenham que ser distintos.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Boax...

Como disse antes, utilizar chaves com ligacoes "reais", podem trazer varios disabores....

Sim, as chaves primarias devem identificar de modo unico e  sem margem para duvidas um registo.

BI, contribruintes e outros do tipos...

Pode a primeira vista parecer boa ideia. Vou fazer compras a uma loja, e o numero de contribuinte ou B.I é unico....

Em teoria...

O numero de contribuinte, para algumas entidades foi alterado recentemente... quem utilizava chaves primarias com estas entidades, teve de alterar uma serie de coisas.

E se quem for fazer compras nao tiver B.I ou se for estrangeiro... nao faz compras?

Exemplo:Situacao que acontece: um determinado soft controla os terceiros, atraves dos numeros de contribuintes...

Vai la uma pessoa fazer compras, e como nao tem ou nao se lembra do NIF, criam um numero ficticio para essa pessoa.

Passados uns meses, a pessoa quer outras compras, e desta vez, leva o NIF real. Altera-se a ficha. E como fica o extracto de conta dessa pessoa?

A venda a dinheiro dela anterior, continua a apontar para o antigo NIF.  A solucao poderia passar por trigger? sim. Mas em tabelas com Gigas de informacao... é mais simples que essa pessoa tenha um identificador numerico. Altera-se o NIF, sem que haja problemas nenhuns. Claro que para isto, a estutura das tabelas tem de ser pensada antes...  ( acho que nao me estou a explicar bem      ;) )...

Numero das facturas:

Aparte( em teoria, os numeros das facturas nao podem ser alterados, conheces algum soft que nao o permita?  :biggrin: )

Exemplo:Em situacoes do dia-a-dia, 2 ou 3 pessoas estao a lancar facturas. depois de gravar uma das pessoas apercebe-se  que se enganou. Anula a factura e volta a lanca-la? sim, em teoria.... na pratica, ninguem te compra o soft...

Exemplo:Um cliente tem 2 ou mais empresas

Ou tens uma base de dados instalada por cada empresa, ou entao tens todas as tabelas (empresas) instaladas na mesma base de dados.

Neste caso, a tabela dos cabecalhos dos documentos irá ter varias facturas nº 1.

Se nao me expliquei bem, digam...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Mais razões, já agora acabamos com o mito teórico, lol.

Usando o NIF como referência vas espalhar os dados informativos por uma data de tabelas quando podia estar apenas numa, isso requer que o código de alteração obedeça uma ordem e que altere em todas as tabelas. Futuramente se for inserida mais uma referência ao NIF (uma extensão qualquer), terá de ser alterado mais código.

Com isto tudo não entendo porque continua a dar coisas na escola que simplesmente não funcionam.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Pronto, convenceram-me.

Vou-me render a esse aspecto. E a proxima BD que criar já terei em atenção esse aspecto.

Realmente essa questão dos dados em falso têm razão, basta carregar sem queres no botão inserir e inseres um registo vazio.

Para responder ao RVG e neste aspecto

Exemplo:Um cliente tem 2 ou mais empresas

Ou tens uma base de dados instalada por cada empresa, ou entao tens todas as tabelas (empresas) instaladas na mesma base de dados.

Neste caso, a tabela dos cabecalhos dos documentos irá ter varias facturas nº 1.

Penso que nesse aspecto se usa a escrita concorrente, recorrendo a Locks e Unlocks, para se garantir que dois registos não sejam inseridos ao mesmo tempo.

E assim garante-se que só existe uma factura numero 1.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Boax....

Penso que nesse aspecto se usa a escrita concorrente, recorrendo a Locks e Unlocks, para se garantir que dois registos não sejam inseridos ao mesmo tempo.

E assim garante-se que só existe uma factura numero 1.

Acho que ha alguma confusão.

Na tabela de cabecalhos de documentos, vais ter varios tipos de documentos. Facturas, vendas a dinheiro, Guias, etc....

Todas elas vao comecar no numero 1 ...  logo aqui, a chave primaria ser o numero nao dava.. tinhas de ter uma tabela por cada tipo de documento...

Mas para complicar mais a coisa, existem clientes, que têm varias empresas na mesma bd.. Este metodo têm inconvenientes, mas tambem tem vantagens.

um dos inconvenientes, é que é mais "complicado" gerir a coisa... Na tabela vais ter por exemplo, varios id´s de empresas, cada uma delas com varios tipos de documentos, e cada tipo de documento, com uma numeracao individual.

na pratica, podes ter, nesta tabela, 2 ou 3 facturas numero 1, so que de empresas diferentes.

Quanto aos locks, prefiro nao entrar nesse campo, senao este topico vira troll    :thumbsup: :biggrin: :) :biggrin:

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Boax...

Como disse antes, utilizar chaves com ligacoes "reais", podem trazer varios disabores....

Sim, as chaves primarias devem identificar de modo unico e  sem margem para duvidas um registo.

BI, contribruintes e outros do tipos...

Pode a primeira vista parecer boa ideia. Vou fazer compras a uma loja, e o numero de contribuinte ou B.I é unico....

Em teoria...

O numero de contribuinte, para algumas entidades foi alterado recentemente... quem utilizava chaves primarias com estas entidades, teve de alterar uma serie de coisas.

E se quem for fazer compras nao tiver B.I ou se for estrangeiro... nao faz compras?

Exemplo:Situacao que acontece: um determinado soft controla os terceiros, atraves dos numeros de contribuintes...

Vai la uma pessoa fazer compras, e como nao tem ou nao se lembra do NIF, criam um numero ficticio para essa pessoa.

Passados uns meses, a pessoa quer outras compras, e desta vez, leva o NIF real. Altera-se a ficha. E como fica o extracto de conta dessa pessoa?

A venda a dinheiro dela anterior, continua a apontar para o antigo NIF.  A solucao poderia passar por trigger? sim. Mas em tabelas com Gigas de informacao... é mais simples que essa pessoa tenha um identificador numerico. Altera-se o NIF, sem que haja problemas nenhuns. Claro que para isto, a estutura das tabelas tem de ser pensada antes...  ( acho que nao me estou a explicar bem      :thumbsup: )...

Numero das facturas:

Aparte( em teoria, os numeros das facturas nao podem ser alterados, conheces algum soft que nao o permita?  :biggrin: )

Exemplo:Em situacoes do dia-a-dia, 2 ou 3 pessoas estao a lancar facturas. depois de gravar uma das pessoas apercebe-se  que se enganou. Anula a factura e volta a lanca-la? sim, em teoria.... na pratica, ninguem te compra o soft...

Exemplo:Um cliente tem 2 ou mais empresas

Ou tens uma base de dados instalada por cada empresa, ou entao tens todas as tabelas (empresas) instaladas na mesma base de dados.

Neste caso, a tabela dos cabecalhos dos documentos irá ter varias facturas nº 1.

Se nao me expliquei bem, digam...

Não querendo entrar pela discussão entre escolha de chaves naturais VS. chaves criadas, todos esses exemplo são de campos que, embora pareça chaves naturais, acabam por não o ser. Por exemplo, um BI, que para nós é um número, numa base de dados, quase sempre deverá ser colocado com um conjunto de caracteres, seja VARCHAR, seja de outro tipo, e esse tipo de dados não devem ser usados para chaves primárias.

Embora perceba o objectivo dos exemplos, acho que são maus exemplos, colocaria quase sempre todos esses dados em campos de texto logo nunca seriam considerados como chaves naturais.

Sou defensor do que é melhor para o problema, sejam chaves naturais ou artificiais, e as chaves artificiais também têm muitos problemas, especialmente se forem sequências ou campos incrementados automáticamente pelo motor de base de dados.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Boax...

exemplo, um BI, que para nós é um número, numa base de dados, quase sempre deverá ser colocado com um conjunto de caracteres, seja VARCHAR, seja de outro tipo

Não te importarias de explicar melhor?

Sou defensor do que é melhor para o problema, sejam chaves naturais ou artificiais, e as chaves artificiais também têm muitos problemas, especialmente se forem sequências ou campos incrementados automáticamente pelo motor de base de dados.

O que entendes por chaves artificiais?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Chaves artificiais são campos usados como chaves que nada têm com os dados que pretendem identificar, isso é o que considero chaves artificiais, talvez o termo não seja o mais correcto.

Quanto aos tipos de dados, se não preciso de fazer calculos com os dados, os mesmos são mais fáceis de manipular quando em texto, é claro que, como tudo, existem vantagens e desvantagens. Dependendo do motor a usar, o uso de VARCHAR pode ter ou não penalizações significativas quando usados como chaves e a escolha vai depender tanto dessa implicações como do objectivo dos dados.

A única coisa que quero realçar é mesmo isso, abandonar as chaves naturais não é algo que se deva seguir ou aconselhar e a teoria é baseada na prática. Tudo vai depender do que estamos a fazer.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Boax...  :P

Antes de mais, que ninguem interprete isto como casmurice minha, mas apenas como troca de ideias e esclarecimentos para futuras situacoes que me possam surgir pela frente...  :biggrin:

chaves artificiais também têm muitos problemas, especialmente se forem sequências ou campos incrementados automáticamente pelo motor de base de dados.

Como pelos vistos temos uma nocao identica de chave artifical, em que situacoes utilizas estas chaves em que nao sejam sequenciais e nao sejam incrementadas automaticamente pelo motor do sgbd?

Quanto aos tipos de dados, se não preciso de fazer calculos com os dados, os mesmos são mais fáceis de manipular quando em texto

Em que te baseias para dizer isso?

Dependendo do motor a usar, o uso de VARCHAR pode ter ou não penalizações significativas quando usados como chaves

Tendo em conta o modo como é lido uma coluna deste tipo, existem sempre penalizacoes ( pode-se poupar em espaco, mas isso tem custos em termos de performances...)  se ainda por cima for uma chave, ao compara-la com outra coluna...  :thumbsup:  claro esta, que se for a nivel academico, nao se nota diferenca... agora quero ver isso na pratica, com tabelas de varias centenas de milhares de linhas, a fazer juncoes com outras tabelas com o mesmo porte.

A única coisa que quero realçar é mesmo isso, abandonar as chaves naturais não é algo que se deva seguir ou aconselhar e a teoria é baseada na prática.

:) 

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora