Solucionado (ver solução)
Solucionado
(ver solução)
2
respostas

Desafio: calculando pedidos

MINHA RESOLUÇÃO

  1. Dados de entrada:
  • Identificação automática:
    nome_cliente, telefone, endereco;
  • Preços fixos:
    preco_hamb = 12, preco_batata = 7, preco_refri = 5;
  • Quantidades (definidas pelo usuário):
    qtd_hamb, qtd_batata, qtd_refri;
  1. Algoritmo:
  • Coletar as quantidades de cada item;
  • Cálculo de subtotais:
    total_hamb = preco_hamb * qtd_hamb
    total_batata = preco_batata * qtd_batata
    total_refri = preco_refri * qtd_refri
  • Cálculo do valor final:
    valor_total = total_hamb + total_batata + total_refri
  1. Saída de dados
  • Exibir o extrato do pedido contendo: identificação do cliente, itens com suas respectivas quantidades e valores;
  • Apresentar o valor total a pagar.

Dúvida: se eu fosse gerar um ID do pedido de forma automática e exclusiva, o ideal seria importar a biblioteca datetime ou existe outra mais indicada? em sistemas reais, como costumam estruturar essa 'chave' que vincula o cliente ao pedido?

2 respostas
solução!

Olá, Luísa! Tudo bem?

Sua resolução para o desafio está excelente. Você estruturou muito bem a lógica de entrada, processamento e saída, que é a base fundamental de qualquer algoritmo.

Sobre sua dúvida técnica, essa é uma pergunta muito pertinente e nos leva para o que chamamos de modelagem de dados em sistemas reais.

Sobre o ID automático e exclusivo

Usar a biblioteca datetime (ou data e hora) é um caminho comum para iniciantes, mas em sistemas reais, apenas o tempo pode não ser suficiente. Se dois pedidos forem feitos no exato mesmo milissegundo, você teria uma colisão de IDs.

Aqui estão as formas mais comuns de estruturar essa "chave":

  • UUID (Universally Unique Identifier): É um padrão muito utilizado. Ele gera uma sequência alfanumérica (como 550e8400-e29b-41d4-a716-446655440000) que é matematicamente garantida como única no mundo. Não depende de uma sequência e não revela quantos pedidos seu sistema já teve.
  • ID Serial (Auto-incremento): É o modelo mais clássico em bancos de dados. O sistema começa no 1 e vai somando (1, 2, 3...). É simples, mas em sistemas muito grandes pode causar gargalos de performance.
  • Chaves compostas: Em alguns cenários, a chave é uma combinação de informações, como ID_CLIENTE + TIMESTAMP.

Como vincular o cliente ao pedido?

Em sistemas profissionais, utilizamos o conceito de Chave Estrangeira (Foreign Key). Imagine duas tabelas separadas:

  1. Tabela clientes: Guarda apenas os dados da pessoa (Nome, Telefone, Endereço) e tem um id_cliente único.
  2. Tabela pedidos: Guarda os dados da compra, o id_pedido e também uma coluna chamada id_cliente.

Dessa forma, o sistema não precisa repetir o nome e o endereço do cliente em cada pedido. Ele apenas "aponta" para o ID do cliente que realizou aquela compra. Isso evita erros de digitação e economiza espaço no banco de dados.

Sugestão de leitura

Se você quiser explorar como isso funciona no Python, por exemplo, procure sobre a biblioteca uuid. Ela é a mais indicada para gerar esses IDs exclusivos de forma segura.

Sua lógica de programação está no caminho certo. Continue com esse olhar curioso sobre como as coisas funcionam "por baixo do capô"!

Alura Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!

Olá, Lorena!
Muito obrigada por detalhar esses conceitos.
Faz total sentido que, em sistemas de escala global, o tempo sozinho possa causar "colisões" de IDs. Achei legal o conceito de Chave estrangeira. Percebi que, sem saber, estava pensando de forma "redundante" ao repetir os dados do cliente no pedido. Estruturar o sistema para apenas "apontar" para o id_cliente deixa tudo muito mais limpo e organizado.
Obrigada pelo link de leitura e por enriquecer meu aprendizado!