Jump to content
JCQS

Tabela sem «Primary Key» para «DataGridView»

Recommended Posts

JCQS

Cumprimentos.

Estou a criar uma tabela SQL para recolha diária de dados com os seguintes campos:

Data (Date)

Nome_Operador (string)

Posto_Trabalho (string)

Numero_Obra (int)

Horas (time)

Nenhum destes campos é «único» pelo que não posso criar «PrimarY KeY» (julgo eu...)

Prevejo a introdução de dados através de um formulário com três «ComboBox» (Data/Nome/Posto)

e de uma «DataGridView»  para Numero_obra e Horas

Dúvidas:Poderei trabalhar com uma tabela sem «PrimarY KeY» ?

        Criar um campo (inútil) só para a «PrimarY KeY» ?

        Trabalhar com outro tipo de dados sem ser Tabelas ?

        Outra solução ?

Agradecido por Ajuda

Share this post


Link to post
Share on other sites
José Lopes

So gostava de saber como é que depois identificas cada registo sem primary key....

Um campo de primary Key, não só é indispensável, com provavelmente é o mais importante da tua estrutura de dados..

Que queres fazer com esses dados?? podes usar XML também..mas francamente eu ia para uma base de dados à séria.


Quando te pedirem peixe.... ensina-os a Pescar!!Hum..lálálálá!!

Share this post


Link to post
Share on other sites
JCQS

So gostava de saber como é que depois identificas cada registo sem primary key....

Que queres fazer com esses dados?? podes usar XML também..mas francamente eu ia para uma base de dados à séria.

Esta tabela servirá especialmente de apoio a outra tabela «Folha_de_Obra» onde se encontra o «Valor_Previsto» para cada «Posto_Trabalho» e onde um campo «Valor_real» receberá a totalidade dos valores também por «Posto_Trabalho» para se calcularem os «Desvios».

Isoladamente servirá apenas para consulta e confirmação da produção anual .

Estava a considerar fazer estas tabelas em SQL Server.Quando diz "eu ia para uma base de dados à séria." a qual é que se está a referir ?

Cumprimentos

Share this post


Link to post
Share on other sites
José Lopes

A uma desse tipo por exemplo....isto porque?

Porque existem outros métodos de armazenar dados, tipo txt ou mesmo XML....

Mas se o tua ideia é criar uma base de dados relacional, PRECISAS MESMO de definir chaves primárias..


Quando te pedirem peixe.... ensina-os a Pescar!!Hum..lálálálá!!

Share this post


Link to post
Share on other sites
JCQS

A uma desse tipo por exemplo....isto porque?

Porque existem outros métodos de armazenar dados, tipo txt ou mesmo XML....

Prevejo entre 20.000 a 30.000 registos anuais.Se guardar dados alguns anos fica uma quantidade de dados que talvez não seja muito prático armazenar e gerir dados em tipo texto.

XLM não domino pelo que tem que ficar provisoriamente fora de causa !!!

Por outro lado como é para interligar com outras tabelas  o SQL e  VB.NET parecem ser a melhor escolha.

Portanto o problema mantêm-se:

DATA, NOME, POSTO_PRODUTIVO, Nº OBRA e HORAS não são únicos pelo que não podem ter a PRIMARY KEY

Posso criar um novo campo. por ex. ID sequencial e atribuir-lhe a PRIMARY KEY

Prevejo porém algumas dificuldades na introdução e alteração de dados, porque tenho tenho que determinar

se o registo existe e guardar o ID ou se é novo e saber qual é o último.

Poderia também dividir estes campos por várias tabelas, mas além de ir complicar, confesso que me sinto um pouco bloqueado na escolha de um esquema funcional

Por isso estou a tentar saber, se alguém deparou com uma situação semelhante e como a resolveu, e caso a queira partilhar fico muito agradecido

OBRIGADO

Share this post


Link to post
Share on other sites
José Lopes

Não tou entender o teu problema. Cada linha na base de dados não pode ter identificador único porque???


Quando te pedirem peixe.... ensina-os a Pescar!!Hum..lálálálá!!

Share this post


Link to post
Share on other sites
JCQS
Em 26/12/2010 às 20:02, José Lopes disse:

Não tou entender o teu problema. Cada linha na base de dados não pode ter identificador único porque???

Trata-se de uma tabela que recolhe a informação diária da produção de cada operador durante todo o Ano

No meu ponto de vista (e devo estar enganado) não posso considerar nenhum dos campos PRIMARY KEY porque não são únicos

DATA  - No mesmo dia varias FOLHAS_DE_OBRA e vários OPERADORES

NOME_OPERADOR - Executa diversas HORAS em várias FOLHAS_DE_OBRA

POSTO_PRODUTIVO - Vários operadores no mesmo POSTO_PRODUTIVO  (turnos)

OBRA -  Vários OPERADORES durante vários dias

Vou tentar dar um exemplo de como ficaria uma tabela depois de 3 dias de introdução de dados

 

26-12-2010 OPERADOR 1 POSTO 1 1111 02:00

26-12-2010 OPERADOR 1 POSTO 1 1112 03:00

26-12-2010 OPERADOR 2 POSTO 1 1111 04:00

26-12-2010 OPERADOR 2 POSTO 1 1114 05:00

27-12-2010 OPERADOR 1 POSTO 1 1110 06:00

27-12-2010 OPERADOR 1 POSTO 2 1120 05:00

27-12-2010 OPERADOR 2 POSTO 2 1111 04:00

27-12-2010 OPERADOR 2 POSTO 1 1118 03:00

28-01-2011 OPERADOR 1 POSTO 2 1119 02:00

 

Receio não ter sido muito claro !

Share this post


Link to post
Share on other sites
ribeiro55

Esse tipo de tabela pode perfeitamente existir sem qualquer identificador único.

Parece-me que a sua função se assemelha a um "log", cujo único propósito é guardar identidades de outras tabelas (e mais alguma informação que não faz sentido ser replicada nas tabelas originais), de forma contínua e sem movimentos para além de consultas.

Para fazeres consultas sobre esta tabela, não sei até que ponto os wizards te safam, mas com comandos "à mão" pescas tudo o que precisas com um par de joins.

Devias passar ali o Nome para o ID do operador, caso exista uma tabela com operadores (que é o que faz sentido).

Por outro lado, o identificador único também não morde... mas também não serve para nada neste caso.


Sérgio Ribeiro


"Great coders aren't born. They're compiled and released"
"Expert coders do not need a keyboard. They just throw magnets at the RAM chips"

Share this post


Link to post
Share on other sites
JCQS

Parece-me que a sua função se assemelha a um "log", cujo único propósito é guardar identidades de outras tabelas (e mais alguma informação que não faz sentido ser replicada nas tabelas originais), de forma contínua e sem movimentos para além de consultas.

Devias passar ali o Nome para o ID do operador, caso exista uma tabela com operadores (que é o que faz sentido).

Quanto ao ID do OPERADOR perfeitamente correto. Aliás também posso (e devo) usar ID do POSTO_PRODUTIVO

O problema (penso eu) é que esta tabela é para actualizar diariamente !!!

A ideia será o OPERADOR preencher através de um DataGridView  a produção diária (com a possibilidade de alterações em datas anteriores), e parece não ser possível inserir a alterar os dados

Também é verdade que um ID (inútil) único não morde... e possivelmente terá que ser essa solução

Tenho também estudado a possibilidade de uma chave composta. Mas parece-me que teria que usar 4 campos (um deles DATE) e parece-me que iria dar uma enorme barafunda...

Gostaria da Vossa opinião sobre estas (ou outras) possibilidades.

Share this post


Link to post
Share on other sites
ribeiro55

Se existe a possibilidade, nem que remota, de existir edição de registos, não há qualquer dúvida: ID único.

Neste caso passa de inútil para fulcral.

Que nem te passe por a cabeça aplicar chaves compostas com datas ;)


Sérgio Ribeiro


"Great coders aren't born. They're compiled and released"
"Expert coders do not need a keyboard. They just throw magnets at the RAM chips"

Share this post


Link to post
Share on other sites
shumy

Pelo meu ponto de vista a FK e PK deveriam ser sempre campos que não fossem utilizados para dados, e deveriam de existir sempre.

A separação dos campos de identificação e referência dos campos de dados é uma das melhores práticas em BD.

Bem sei, não é isto que apregoam os teóricos, mas eu também não vivo da teoria.


Aqui há coisa de 2 anos fazia umas malhas de croché, depois fartei-me e fui para informática!

Share this post


Link to post
Share on other sites
José Lopes

Desculpem a minha insistência... mas uma tabela, numa estrutura de dados tabelas sem identificadoresúnicos, deve ser do mais esquisito que já vi... mas, confesso que também não vi assim tanto como isso...

o que é facto, é que hoje não precisas, e amanhã por alguma razão decides fazer alguma alteração à estrutura de dados, ou precisas de fazer algumas consultas que inicialmente não estavam previstas, ou migrar os dados...ou o que seja...ups-... lá se vai a integridade referencial...

Concordo que se fosse uma espécie de log (tb tenho isso feito para recolher inputs (apenas!)) de facto torna-se desnecessário..normalmente isso até fica num txt... mas... quando esses dados são carregados para base de dados, ainda que esse registo possa ser desdobrado por várias tabelas, esses registos têm identificador único.


Quando te pedirem peixe.... ensina-os a Pescar!!Hum..lálálálá!!

Share this post


Link to post
Share on other sites
JCQS

ID único.Neste caso passa de inútil para fulcral.

A separação dos campos de identificação e referência dos campos de dados é uma das melhores práticas em BD.

Optei por criar um campo ID para PRIMARY KEY com a propriedade IDENTITY activada, usando SCOPE_IDENTITY para saber o último registo, e tem funcionado bem

Obrigado pelas vossas sugestões

Share this post


Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.