cheires Posted November 29, 2007 at 02:57 PM Report Share #151142 Posted November 29, 2007 at 02:57 PM 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. Link to comment Share on other sites More sharing options...
RVG Posted November 29, 2007 at 03:07 PM Report Share #151144 Posted November 29, 2007 at 03:07 PM Boax.... ALTER TABLE A_TUA_TABELA AUTO_INCREMENT=N N-Valor inicial. Nem vou perguntar em que situcao pretendes fazer isto.... Link to comment Share on other sites More sharing options...
cheires Posted November 29, 2007 at 03:10 PM Author Report Share #151147 Posted November 29, 2007 at 03:10 PM 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 😞 Link to comment Share on other sites More sharing options...
saunde Posted November 29, 2007 at 08:44 PM Report Share #151211 Posted November 29, 2007 at 08:44 PM 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... Um blog :Sem Cafeína Link to comment Share on other sites More sharing options...
RVG Posted November 30, 2007 at 04:03 PM Report Share #151381 Posted November 30, 2007 at 04:03 PM boax... O meu comentário foi porque: Para pedires isso quase de certeza que usas chaves naturais... acho que é assim que se chamam ? 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. Link to comment Share on other sites More sharing options...
Tiago Salgado Posted December 1, 2007 at 12:53 PM Report Share #151536 Posted December 1, 2007 at 12:53 PM RVG, podias explicar porque defendes a não utilização do BI (ou outros) para chave primária? Link to comment Share on other sites More sharing options...
cheires Posted December 4, 2007 at 03:05 PM Author Report Share #152213 Posted December 4, 2007 at 03:05 PM 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 Link to comment Share on other sites More sharing options...
shumy Posted December 4, 2007 at 03:29 PM Report Share #152218 Posted December 4, 2007 at 03:29 PM 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. Aqui há coisa de 2 anos fazia umas malhas de croché, depois fartei-me e fui para informática! Link to comment Share on other sites More sharing options...
pedrotuga Posted December 4, 2007 at 03:44 PM Report Share #152227 Posted December 4, 2007 at 03:44 PM 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. Link to comment Share on other sites More sharing options...
RVG Posted December 4, 2007 at 03:47 PM Report Share #152228 Posted December 4, 2007 at 03:47 PM 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? 😁 ) 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... Link to comment Share on other sites More sharing options...
shumy Posted December 4, 2007 at 03:57 PM Report Share #152231 Posted December 4, 2007 at 03:57 PM 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. Aqui há coisa de 2 anos fazia umas malhas de croché, depois fartei-me e fui para informática! Link to comment Share on other sites More sharing options...
cheires Posted December 5, 2007 at 05:01 PM Author Report Share #152487 Posted December 5, 2007 at 05:01 PM 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. Link to comment Share on other sites More sharing options...
RVG Posted December 5, 2007 at 05:32 PM Report Share #152491 Posted December 5, 2007 at 05:32 PM 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 👍😁🙂😁 Link to comment Share on other sites More sharing options...
Knitter Posted December 5, 2007 at 07:08 PM Report Share #152513 Posted December 5, 2007 at 07:08 PM 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? 😁 ) 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. www.sergiolopes.eu Link to comment Share on other sites More sharing options...
RVG Posted December 6, 2007 at 10:00 AM Report Share #152617 Posted December 6, 2007 at 10:00 AM 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? Link to comment Share on other sites More sharing options...
Knitter Posted December 6, 2007 at 04:27 PM Report Share #152670 Posted December 6, 2007 at 04:27 PM 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. www.sergiolopes.eu Link to comment Share on other sites More sharing options...
RVG Posted December 6, 2007 at 06:20 PM Report Share #152700 Posted December 6, 2007 at 06:20 PM Boax... 😛 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... 😁 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... 👍 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. 🙂 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now