Primarykey tem sempre de existir ??

[baguera]

Sou programador de VB6 e estou a passar para o vb .net

Preciso da vossa ajudar a esclarecer o seguinte:

1- Estou a usar SQL Express 2008 e o VB2010 Express

2- Criei uma base de dados(Teste.MDF), onde tem 2 tabelas

Cliente:                          Movimentos:

NumCli (PK)                    NumCli(FK)

Nome                            Data

                                    Quantidade

                                    Valor

Tenho neste caso uma relaçao de 1 para muitos.

Reparei que na tabela Cliente como tenho uma chave primaria, automaticamente foi criado os comandos (Update, Delete, Add).

Mas na tabela movimentos NAO foi criado os comandos (UPDATE e DELETE), visto nao ter uma chave primaria.

A minha pergunta é:

um cliente tem varios movimentos, como consigo apagar um unico determinado movimento na tabela movimentos ??

Sou obrigado a ter em cada tabela SEMPRE uma chave primaria, nem que seja um campo de autoincremento ??

Em VB6, ADO ou DAO como sabia sempre o registo aonde estava posicionado, bastava fazer DELETE.

Aqui pelo que percebi com os dynaset nao funciona assim.

Agradecia imenso que me tirassem esta duvida.

Obrigado.

[renafi]

Para o Visual Studio fazer automaticamente esse código manipulação da BD, tens de ter a PK. Mas podes perfeitamente não ter a PK e fazer o código tu. Só uma pergunta: mas sabes qual é a utilidade de ter Chave Primária?

[ruiFernandes]

normalmente eu uso chaves primárias com autoincremento para os id, para efectuar operações na bd

[pedrotuga]

A chave primária é o conceito base de uma relação (tabela). Se não tens uma forma de referir  de forma não ambigua a um conjunto de dados então para que é que estás a usar uma base de dados? É que não te serve absolutamente para nada, nesse caso.

Não estou a exagerar nem a ser sarcástico, uma base de dados relacional é programa que te permite aceder a dados usando como referência chaves. Se não fizer isso, não é um motor de base de dados relacional, é uma estrutura de dados de outro tipo.

A chave primária pode ser constituida por mais do que uma coluna, mas tem que existir, de outra forma, como é que o motor de base de dados é suposto adivinhar a informação que pedes, se tu não lhe estás a dizer expressamente o que queres?

[baguera]

Desde já agradeço as respostas. Muito obrigado.

O que acontece é que na tabela de Movimentos se pedir todos os movimentos de um determinado cliente, por ex. para uma grelha, eles aparecem, mas depois se quiser eliminar/actualizar os dados da linha apenas selecionada nao faz.

Acho que é pelo facto de nao ter uma chave primaria para informar qual o registo a apagar.

Em VB6 como os registos estao ligados(ADO/DAO) basta dizer delete e como ele esta no registo fisico da Base de dados, logo sabe qual é e apaga.

Em VB6 não precisava de ter uma chave primaria na tabela Movimentos para fazer isto.

Em VB .net a base de dados não está "ligada", os dataset tipados apenas sao carregados com dados, mas depois temos de informar quais os dados a eliminar/actualizar, correcto ???

Este é o facto pelo qual temos de ter sempre em todas as tabelas uma chave primaria ??

Visto o VB6 não ter mais futuro e tenho varios projectos, vou ter de migrar,

Obrigado pelas dicas

[baguera]

normalmente eu uso chaves primárias com autoincremento para os id, para efectuar operações na bd

Se tiver numa grelha os movimentos todos de um determinado cliente e seleccionar uma linha e fizer DELETE como o registo esta sempre apontado à base de dados ele elimina sem problema, em VB6.

Mas em VB .net pelos vistos como o dataset tipado apenas tem os dados carregados depois precisa de um meio unico de distinguir qual o registo pretendo anular, certo ??

[baguera]

Para o Visual Studio fazer automaticamente esse código manipulação da BD, tens de ter a PK. Mas podes perfeitamente não ter a PK e fazer o código tu. Só uma pergunta: mas sabes qual é a utilidade de ter Chave Primária?

Sim, sei o que são chaves, estou a migrar de VB6 para Vb .net e estou sendo confrontado com algumas GRANDES diferenças, por isso agradeço imensso a vossa ajuda.

[bsccara]

Deves ter sempre um campo de desambiguação do registo/elemento. Nunca deves depender da ordem dos registos/elementos para identificar os mesmos.

Em relação à tua pergunta original, ou crias um campo numerado na tabela de movimentos para identificar os movimentos por cliente ou usas o campo 'data' (mas isso provavelmente não dará).

Isto não tem nada a ver com a presença ou ausência de chaves primárias.

A chave primária pode ser constituida por mais do que uma coluna, mas tem que existir, de outra forma, como é que o motor de base de dados é suposto adivinhar a informação que pedes, se tu não lhe estás a dizer expressamente o que queres?

A chave primária não tem que existir para isso, apenas pode ser mais eficiente para a base de dados. A selecção do âmbito da operação é feita indicando os valores esperados em colunas. A chave primária é necessária para permitir à base de dados a manutenção da integridade referencial e singularidade dos dados na(s) coluna(s) envolvida(s).

[pedrotuga]

A chave primária não tem que existir para isso, apenas pode ser mais eficiente para a base de dados. A selecção do âmbito da operação é feita indicando os valores esperados em colunas. A chave primária é necessária para permitir à base de dados a manutenção da integridade referencial e singularidade dos dados na(s) coluna(s) envolvida(s).

Sem querer ser o maior da minha aldeia... Não. Isso está errado.

Estás-te a referir a adicionar uma coluna numérica a uma tabela com o único intuito de a usar como chave. Isso pode-se fazer ou não, mas se não se fizer, tens na mesma que ter uma chave primária. Não é é essa coluna.

Por definição, uma base de dados relacional, é um sistema de armazenamento de dados em que estes são guardados em tabelas (ou relações) que podem ser consultadas de forma não ambígua utilizando a chave primária. Que consequentemente é única por linha. A chave primária não tem que ser uma coluna com um 'id', pode ser um conjunto de colunas que contenham dados que no seu conjunto sejam sempre distintos. Mas tem que existir. Se não, não estamos a falar de uma base de dados relacional.

Posto isto, uma base de dados relacional pode ter integridade de dados ou não. Se tiver, têm que existir obrigatoriamente chaves ESTRANGEIRAS a apontar para cada tabela relacionada. As chaves primárias por si só, não garantem integridade de dados.

[baguera]

Mais uma vez obrigado.

Resumindo tenho de ter uma Primaykey em cada tabela.

No caso do Cliente como o numero NUNCA é igual posso defenir como primarykey.

No caso da tabela movimentos vou criar um campo IDmov Autoincremental e defenir como Primarykey.

Pelo que entendi é isto, certo ??

Obrigado.

[ruiFernandes]

na tabela cliente também convém teres a chave primária também com autoincremento

[pedrotuga]

Mais uma vez obrigado.

Resumindo tenho de ter uma Primaykey em cada tabela.

No caso do Cliente como o numero NUNCA é igual posso defenir como primarykey.

No caso da tabela movimentos vou criar um campo IDmov Autoincremental e defenir como Primarykey.

Pelo que entendi é isto, certo ??

Obrigado.

Sim, é isso.

Um conselho pratico:adicionar um id numérico na maior parte das vezes evita futuras chatices. Nem sempre o que parece único é. Por vezes pensamos "ah e tal, este campo nunca se repete, usamo-lo como chave primária", mas depois aparece uma situação em que são precisas mais do que uma coluna com o mesmo identificador.

Adicionalmente, um campo numérico permite perquisas mais rapidas e índices mais eficientes em termos de espaço

[bsccara]

Sem querer ser o maior da minha aldeia... Não. Isso está errado.

Isto não se trata de quem sabe mais mas de aprender uns com os outros discutindo em termos técnicos...

Posto isto, discordo de vários pontos:

Isso pode-se fazer ou não, mas se não se fizer, tens na mesma que ter uma chave primária.

Por definição, uma base de dados relacional, é um sistema de armazenamento de dados em que estes são guardados em tabelas (ou relações) que podem ser consultadas de forma não ambígua utilizando a chave primária. ...  Mas tem que existir. Se não, não estamos a falar de uma base de dados relacional.

Em termos da teoria das bases de dados relacionais tens razão, pois é uma das três regras de integridade. Mas em termos práticos a linguagem SQL (http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt) não obriga a isso; o standard define uma chave primária como uma restrição que garante a singularidade dos dados nas colunas associadas. Não tem nada especificamente a ver com a consulta de dados. Ou seja, podes fazer um SELECT sobre uma tabela sem chave primária sem problema nenhum.

Agora se me disseres que na maioria dos casos deve haver uma chave primária, de acordo. Mas não em termos absolutos.

Convém lembrar que não existe a noção de ordem das linhas dos resultados do SQL; se é precisa uma ordem especifica, ela terá de ser indicada na query. Logo não é necessário identificar inequivocamente cada linha para poderem ser consultadas.

Posto isto, uma base de dados relacional pode ter integridade de dados ou não. Se tiver, têm que existir obrigatoriamente chaves ESTRANGEIRAS a apontar para cada tabela relacionada. As chaves primárias por si só, não garantem integridade de dados.

Presumo que queiras dizer integridade referencial; e volto a discordar pois essa também é uma das três regras de integridade do modelo relacional. Quanto ao segundo ponto, eu não disse que bastavam as chaves primárias para manter a integridade referencial, mas sim que são necessárias para isso (o que também não é verdade em absoluto mas em termos práticos).

[baguera]

Já percebi o quanto é essencial ter sempre uma primarykey.

Pois se quisermos eliminar/alterar determinada linha/registo, p.ex., temos de ter nessa linha algo diferente de todas as outras linhas que com uma instrução SQL conseguissemos a selecionar e dizer que pretendemos eliminar/alterar aquele registo especifico.

Dai a necessidade de acrescenar o tal Campo IDmov Autoincremental  e ser primarykey na minha tabela de movimentos, pois muitas vezes o valor deste campo vai ser a unica diferença entre varios registos.

Acho que já apanhei a ideia.

Mas caso nao esteja a pensar bem, agradeço os comentarios.

Obrigado a todos. 😄

[shumy]

Um conselho pratico:adicionar um id numérico na maior parte das vezes evita futuras chatices. Nem sempre o que parece único é. Por vezes pensamos "ah e tal, este campo nunca se repete, usamo-lo como chave primária", mas depois aparece uma situação em que são precisas mais do que uma coluna com o mesmo identificador.

Adicionalmente, um campo numérico permite perquisas mais rapidas e índices mais eficientes em termos de espaço

Deixa-me dizer-te que este é um conselho muito importante. Eu por exemplo separo sempre campos de referência (PK, FK) de campos de dados.

Uma boa chave primária, para além de ser única também deve ser imutável. Uma PK referenciada por várias outras FK, se tiver que ser alterada, é o terror. Um campo de inserção manual está sempre sujeito a erros e como tal não pode ser considerado imutável, tal como o NIF e coisas do género, é um erro utilizar estes campos como PK, apenas são marcados como únicos.