Poderia me explicar melhor?
Respondendo a "Se eu entendi a necessidade, aqui voce faria um..." dentro da publicação Problema com SQlite
1
2
Basicamente as tabelas que voce criou se relacionam entre elas, sendo assim voce consegue fazer a consulta dos dados juntando as informacoes desejadas, exemplo:
"saber o preco da roupa vendido" teria que ir na tabela de vendas e perguntar qual foi o item vendido (select id_roupa from vendas) e ai na tabela de roupas perguntar qual o preco (select preco_roupa from roupas), isso pode ser tanto duas consultas (select) quanto fazendo a uniao (join).
2
tem um ponto ai...o preço da roupa deve ser "congelado" no momento da criaçao da venda, usando os relacionamentos sempre volta o preço atual.
acho que por isso o Heytor pergunta se tem como importar o preco_roupa quando cria a venda.
seguindo essa racional diria que nao, que é necessario um novo campo na tabela de Vendas para armazenar
o preco.
quando uma venda for efetuada, no proprio insert na tabela Vendas, como
vc ja tem o id do produto, passe um select que retorna o preco do produto como valor do seu novo campo, algo como SELECT preco_roupa FROM Roupas WHERE ID_Roupa = :ID
1
Concordo que a estrutura poderia ser melhor elaborada por exemplo:
"roupa tem uma nova tabela historico_roupa pois quando existir mudanca no preco do mesmo, vendas anteriores seram imutaveis"
ou ate mesmo:
"uma tabela venda_roupa onde estara as roupas e precos que foram vendidos naquela transacao e sendo assim ter mais de uma roupa por venda se necessario"
Se tratando da estrutura sempre terão pontos diferentes a se pensar e melhorar como uso do MongoDB como banco de dados dependendo da necessidade final ou generalização das tabelas como roupas será item e tera um tipo roupa,tenis,etc...
3
sim sim, concordo totalmente. porem acredito que para a finalidade do exercicio (e aqui estou só chutando) me parece muito uma aula de banco de dados para explicar JOIN e começar a provocar esses questionamentos no processo