Ir para o conteúdo
  • Revista PROGRAMAR: Já está disponível a edição #60 da revista programar. Faz já o download aqui!

He B TeMy

Dúvida na estruturação de uma Base de Dados

Mensagens Recomendadas

He B TeMy

Boa tarde, estou a fazer uma gestão de um restaurante em vb.net e estou com umas dúvidas...

O que têm no menu são os produtos para o consumidor final, tipo: "Frango assado", "Bife" etc...

A minha dúvida é, na base de dados eu terei que ter uma tabela de ingredientes também?

Porque frango assado não leva só o frango... e eu teria de ao clicar retirar do stock frango + batata + arroz + o que seja por assim dizer.

Dúvida é se terei de fazer duas tabelas, (Uma para o que está no menu e outra para os ingredientes em geral) E se eu consigo em Access fazer com que ao retirar um produto duma tabela, ele me descontasse noutra tabela outros produtos.

Alguém me consegue ajudar?

Muito obrigado.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nelsonr

Normalmente tens a tabela dos produtos e talvez uma propriedade a indicar se é menu.

Se for menu, tens outra tabela que terá o ID do produto menu e depois o ID dos produtos relacionados (1->N).

Para atualizar o stock, quando fores retirar o stock de um artigo, se for do tipo menu, retiras tambem de todos os produtos relacionados

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
He B TeMy

Mas é correcto pôr na mesma tabela produtos tipo que acompanham os pratos principais e os pratos principais em si?

Tipo batata junto com "prego no prato" que suponhamos que leva batata?

Não sei se me expliquei bem, ou pela tua ideia estás a falar em ter três tabelas?

Uma para ingredientes, (tudo) outra para o que têm no menu, e outra a indicar se é menu?

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nelsonr

Boas,

não vejo problema nenhum em ter o "prego no prato" na mesma tabela que a "batata".

Até facilita, visto ambos terem as mesmas propriedades (preços, stocks, taxas, etc).

O produto menu é que tem alguma informação extra (produtos relacionados).

A meu ver apenas precisas de 2, produtos e composicaomenu. Exemplo:

Produtos

ID, nome, menu, preço

1, "Batata", false, 0.40€

2, "Ovo", false, 0.70€

3, "Bife", false, 2.50€

4, "Prego no prato", true, 5€

ComposicaoMenu

ID, IDProdutoPrincipal, IDProdutoRelacionado

1, 4, 1

2, 4, 2

3, 4, 3

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
He B TeMy

Acho que não me expliquei bem.

Só os que tão no menu, é que têm preço (estão para venda) os outros são produtos que estão dentro desse prato...

Estamos a falar preço para o consumidor, não o preço que "eu" pago por eles... ainda não inclui isso...

Se eu estiver a fazer confusão peço desculpa.

Editado por He B Te My

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nelsonr

Então podes por mais um campo a indicar se permite venda directa.

E se por exemplo, pedirem um prego no prato e depois um ovo extra?

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
cdaniel.marques

Uma sugestão: na tabela dos pratos, crias um campo ingrediente(x) e quantidade por cada ingrediente.

ID Prato Menu Preço ingrediente1 quantidade1 ingrediente2 quantidade2 ingrediente3 quantidade3

1 "Bitoque" True 5,5€ "bife" 1 "batata" 200 "ovo" 1

2 "Hamburger no Prato" True 5€ "hamburger" 1 "arroz" 200 "batata" 200

Assim podes abater no stock na tabela dos ingredientes, na altura da compra do prato.

ID Ingrediente UnidadeMedida StockDisponivel

1 "bife" un 10

2 "hamburger" un 7

3 "arroz" gr 3000

4 "batata" gr 5750

...

E depois adiciona um Form para abater produtos Extra, que apresente os os ingredientes e podes abater mais uma unidade.

Editado por cdaniel.marques

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
He B TeMy

Uma sugestão: na tabela dos pratos, crias um campo ingrediente(x) e quantidade por cada ingrediente.

ID, Prato, menu, preço, ingrediente1, quantidade, ingrediente2, quantidade

1, "Bitoque", false, 0.40€, "bife", 1, "batata", 200, "ovo", 1

2, "Hamburger no Prato", true, 5€, "hamburger", 1, "arroz", 200, "batata", 200

Assim podes abater no stock na tabela dos ingredientes, na altura da compra do prato.

E depois adiciona um Form para abater produtos Extra, que apresente os os ingredientes e podes abater mais uma unidade.

Tenho que ver melhor isso, não estou muito habituado a trabalhar com base de dados (Access)...

Era exactamente como puseste aí ? "Ingrediente1" "Ingrediente2", punha assim? (Com os nomes deles como é obvio acho eu.)

nelsonr, pois, nesse caso teria que fazer uma groupbox, com os acompanhantes dos pratos principais que também daria para venda directa.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
cdaniel.marques

Tenho que ver melhor isso, não estou muito habituado a trabalhar com base de dados (Access)...

Era exactamente como puseste aí ? "Ingrediente1" "Ingrediente2", punha assim? (Com os nomes deles como é obvio acho eu.)

Se colocares Ingrediente(x) na tabela do access, tens a liberdade criar os ingredientes no programa.

Se fizeres como estas a dizer, também podes fazer, mas cada vez que adicionares um prato com um ingrediente novo, implica alteração de código: terias de alterar adicionar uma coluna à tabela na base de dados, e alterar o código do programa para procurar a nova coluna.

PS: Corrigi a estrutura q tinha no Post #7

Editado por cdaniel.marques

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
He B TeMy

Se colocares Ingrediente(x) na tabela do access, tens a liberdade criar os ingredientes no programa.

Se fizeres como estas a dizer, também podes fazer, mas cada vez que adicionares um prato com um ingrediente novo, implica alteração de código: terias de alterar adicionar uma coluna à tabela na base de dados, e alterar o código do programa para procurar a nova coluna.

PS: Corrigi a estrutura q tinha no Post #7

Já vi, muito obrigado.

Mas como consigo adicionar ingredientes com o ingrediente(x) no programa?

Não tou a perceber bem, isso é basicamente adicionar colunas com o nome do ingrediente novo?

Obrigado.

Editado por He B Te My

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
cdaniel.marques

Boa tarde, estou a fazer uma gestão de um restaurante em vb.net e estou com umas dúvidas...

Se estás a fazer o programa em VB.NET, consegues fazer alterações à base de dados:

Adicionar registos a tabelas, editar registos e eliminar, apartir do programa que estás a construir.

Imaginado que já tens um Form para escolher o prato e fazer a venda, terás de adicionar dois Forms de configuração, que irão ser utilizados por exemplo pelo gestor do restaurante:

- Um para gerir ingredientes.(Adicionar, Editar, Eliminar)

- Outro para gerir os pratos.

Neste Form, adicionas por exemplo uma caixa de texto para nome prato, preço, etc e depois duas text box's, ingrediente(x) e um quantidade(x), para cada um dos ingredientes. (igual ao numero de colunas que tens na base de dados, seja 10 por exemplo)

Assim, quando fizesses gravar o prato, irias correr um instrução SQL, deste genero, tendo em conta o exemplo acima:

"INSERT INTO tabelapratos VALUES ('Hamburger no Prato', '5', 'hamburger', '1', 'batatas', '200', 'arroz', '150', ...)

Na altura da venda, procuras pelo prato escolhido cada um dos ingredientes que estiver preenchido (instrução ou instruções SQL para ler registo base dados) e subtrais (instrucao para editar registo) ao Stock do Ingrediente (tabela ingredientes) a quantidade(x) usada no prato, para cada um dos ingredientes.

Em VB adicionas registos. As colunas devem ser adicionadas no Access.

Editado por cdaniel.marques

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
He B TeMy

Sim, eu entendo e estou a finalizar isso tudo.

Quanto no vb não adicionar colunas, e se algum dia fosse preciso mais uma coluna de ingredientes? Sem tar eu a adicionar um número "monstruoso" de colunas de ingredientes... não seria melhor dar para adicionar outras colunas? Mas sim, eu entendo isso.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nelsonr

Não era bem mais simples teres um registo para cada... isso vai dar tudo ao mesmo... produtos

Editado por nelsonr

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
He B TeMy

Não era bem mais simples teres um registo para cada... isso vai dar tudo ao mesmo... produtos

E não foi o que eu disse? Tabela produtos conter tudo o que vai no menu (ser vendido no restaurante) e depois Tabela ingredientes com tudo o que é usado.

Estou certo não estou?

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nelsonr

E porque separas os ingredientes dos produtos?

Porque é que um ovo junto do menu (ingrediente) é diferente de um ovo que é adicionado ao menu (extra) e é diferente de um ovo vendido sozinho (produto)

Outro exemplo, o menu pode conter uma bebida (ingrediente) e podes vender a bebida à parte (produto).

Teres isso separado só causa confusão. Tanto tens de tirar do stock uma coca-cola que é vendida no menu, como uma coca-cola vendida sozinha

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
He B TeMy

E porque separas os ingredientes dos produtos?

Porque é que um ovo junto do menu (ingrediente) é diferente de um ovo que é adicionado ao menu (extra) e é diferente de um ovo vendido sozinho (produto)

Outro exemplo, o menu pode conter uma bebida (ingrediente) e podes vender a bebida à parte (produto).

Teres isso separado só causa confusão. Tanto tens de tirar do stock uma coca-cola que é vendida no menu, como uma coca-cola vendida sozinha

Porque o que têm no menu é constituido pelos seus ingredientes, que eu interligava e retirava do stock as quantidades respectivas para cada um... estou só a pensar se não seria melhor.

Quanto a ser vendido, neste caso, só será para venda tudo o que tiver no menu, lá, se esta ideia for para a frente vai ter também os acompanhamentos (que pode já vir com alguns dos pratos mas se quiser outro pode vir sozinho sem ser preciso pedir outra vez o prato completo).

Estou só a pensar... ajudas são bem-vindas.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
acao

Não era bem mais simples teres um registo para cada... isso vai dar tudo ao mesmo... produtos

concordo plenamente, basedados mais efeciente.

cumps

acao

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
He B TeMy

Então como separo ingredientes que fazem os produtos dos produtos do menu?

Acham melhor fazer uma coluna com "Menu" e por "Sim" ou "Não" em cada um dos "produtos"?

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nelsonr

Dei-te um exemplo no #4.

Julgo ser a melhor forma de implementares o que pretendes, permitindo facilmente definires menus, vender produtos sozinhos ou como ingredientes, e sem ter de alterar a estrutura se quiseres adicionar mais ingredientes mais tarde.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Rui Carlos

E porque separas os ingredientes dos produtos?

Porque é que um ovo junto do menu (ingrediente) é diferente de um ovo que é adicionado ao menu (extra) e é diferente de um ovo vendido sozinho (produto)

Outro exemplo, o menu pode conter uma bebida (ingrediente) e podes vender a bebida à parte (produto).

Teres isso separado só causa confusão. Tanto tens de tirar do stock uma coca-cola que é vendida no menu, como uma coca-cola vendida sozinha

Penso que faz sentido ter as coisas separadas: ingredientes e menus.

São entidades diferentes, que vão provavelmente precisar de ter propriedades diferentes, e que são operados de forma diferente. Para mim isto acaba por ser quase uma questão de modularidade.

A meu ver apenas precisas de 2, produtos e composicaomenu. Exemplo:

Produtos

ID, nome, menu, preço

1, "Batata", false, 0.40€

2, "Ovo", false, 0.70€

3, "Bife", false, 2.50€

4, "Prego no prato", true, 5€

ComposicaoMenu

ID, IDProdutoPrincipal, IDProdutoRelacionado

1, 4, 1

2, 4, 2

3, 4, 3

Vais ter uma relação Produto-Produto, que devia ser Produto-Menu (que impediria logo à partida relações inválidas na tabela ComposicaoMenu). Provavelmente não precisavas do preço nos não-menus, e em vez disso precisavas do stock, que não precisas no menu.


Repara também que se devia começar com:

Produtos

ID, nome, stock

1, "Batata", ...

2, "Ovo", ...

3, "Bife", ...

Menu

ID, nome, preço, produtos

1, "Prego no prato", 5€, {1, 2}

...

Depois de normalizado, este esquema ficava:

Produtos

ID, nome, stock

1, "Batata", ...

2, "Ovo", ...

3, "Bife", ...

Menus

ID, nome, preço

1, "Prego no prato", 5€

...

MenuProduto

IDMenu, IDProduto

1, 1

1, 2

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
He B TeMy

Dei-te um exemplo no #4.

Julgo ser a melhor forma de implementares o que pretendes, permitindo facilmente definires menus, vender produtos sozinhos ou como ingredientes, e sem ter de alterar a estrutura se quiseres adicionar mais ingredientes mais tarde.

Não percebi a parte de ComposiçãoMenu... ?

ProdutoRelacionado e Principal? Principal sendo o que está á venda e o relacionado os que o fazem?

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Rui Carlos

Não percebi a parte de ComposiçãoMenu... ?

ProdutoRelacionado e Principal? Principal sendo o que está á venda e o relacionado os que o fazem?

Tens um produto que pode pertencer a vários menus, e menus com vários produtos, ou seja, uma relação M para N. Como é que implementas uma relação M para N (muitos para muitos)?

Vê isto: http://en.wikipedia.org/wiki/Junction_table

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
He B TeMy

Penso que faz sentido ter as coisas separadas: ingredientes e menus.

São entidades diferentes, que vão provavelmente precisar de ter propriedades diferentes, e que são operados de forma diferente. Para mim isto acaba por ser quase uma questão de modularidade.

Vais ter uma relação Produto-Produto, que devia ser Produto-Menu (que impediria logo à partida relações inválidas na tabela ComposicaoMenu). Provavelmente não precisavas do preço nos não-menus, e em vez disso precisavas do stock, que não precisas no menu.


Repara também que se devia começar com:

Produtos

ID, nome, stock

1, "Batata", ...

2, "Ovo", ...

3, "Bife", ...

Menu

ID, nome, preço, produtos

1, "Prego no prato", 5€, {1, 2}

...

Depois de normalizado, este esquema ficava:

Produtos

ID, nome, stock

1, "Batata", ...

2, "Ovo", ...

3, "Bife", ...

Menus

ID, nome, preço

1, "Prego no prato", 5€

...

MenuProduto

IDMenu, IDProduto

1, 1

1, 2

Podes elaborar mais na parte do MenuProduto com o Menu?

Estou meio confuso no que essa tabela servirá... tou a precisar de dormir...

Amanhã testo isso, mas se pudesses elaborar nesse pensamento, como disse, não estou muito familiarizado em Access.

Obrigado :)

Edit: Reli e já entendi.

Agora só falta pôr em "prática" para ver se tenho mais dúvidas... mas isso só amanhã.

Obrigado.

Editado por He B Te My

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
nelsonr

Penso que faz sentido ter as coisas separadas: ingredientes e menus.

São entidades diferentes, que vão provavelmente precisar de ter propriedades diferentes, e que são operados de forma diferente. Para mim isto acaba por ser quase uma questão de modularidade.

A meu ver esse é o problema que está a causar confusão, pensar como entidades diferentes.

Como disse antes, por exemplo, tanto podes vender uma coca-cola directamente ou como parte de um menu.

Porque teres a bebida em duas tabelas diferentes?

E tanto tens preços e taxas nas bebidas directas como nos menus.

Outro exemplo que tambem tinha dado, é queres um ovo extra num menu. Vais ter de ter preço no ovo

E por exemplo, depois tens a tabela de vendas em que tens a lista de produtos vendidos.

Vais ter em cada registo o ID do produto vendido, que tanto pode ser o menu como o "ingrediente".

Se forem tabelas diferentes só causa confusao, vais ter de ter campos diferentes para relacionar.

Partilhar esta mensagem


Ligação 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

×

Aviso Sobre Cookies

Ao usar este site você aceita os nossos Termos de Uso e Política de Privacidade. Este site usa cookies para disponibilizar funcionalidades personalizadas. Para mais informações visite esta página.