Estou com uma dúvida na seguinte ligação N para N.
- É correto ter colunas específicas nessa tabela de
orcamento_has_item? - Ou como seria a forma correta?
Normal, você pode ter “N” outras colunas além das chaves que se relacionam com as tabelas de origem.
É complicado falar se é o certo ou errado sem saber como vai funcionar, o trivial não é ter, ou seja, somente as chaves primárias das duas relações, mas, tem sistemas que fazem essa “gambiarra” para solucionar algum problema que ela mesmo está criando.
Vendo assim me parece um relacionamento 1 para N onde 1 Orçamento tem seus Item de Orçamento, não precisando ter um N para M, do jeito que está ai parece que complicou o fácil.
Falta contexto mesmo para tomar uma decisão mais próxima da realidade, porque do jeito que está ai os itens serão cadastrados separados, mas, ai não é a tabela de produtos?
Bom fica vários questionamentos em aberto.
É correto, se estiver dentro do que o cliente necessita.
1 curtida
Só por curiosidade, porquê você acha que ter colunas distintas em uma tabela resultante de uma relação N x N é gambiarra?
Na verdade, é a mesma lógica de uma NF: cada NF tem um cliente (CPF ou CNPJ) e um ou vários itens. Cada cliente pode ter várias NF.
Cada item pode estar em várias NF.
Logo:
NF : Cliente é uma relação 1 : N
NF Item: Relação N : M
Como resolver?
Cria-se uma tabela associativa NF_ITEM ou mais popular ITEM_VENDA e esta conterá a PK da NF, a PK do item (que pode ser a PK composta da tabela) e outros dados, como: quantidade, subtotal, etc.
1 curtida
Considerando esse seu exemplo, no caso é o mesmo que fiz na tabela orcamento_has_item, porém com um nome diferente, estou certo ?
1 curtida
Também não entendi, é muito comum.
1 curtida
Justamente, ainda mais dentro deste cenário de “N” produtos para “1” orçamento ou (pedido, NF, venda, compra… ), por isso fiquei curioso em saber.
1 curtida
Veja o contexto, o que ele precisa fazer é 1 para N e não como ele está fazendo N para M e está parecendo gambiarra no aspecto de fazer errado (isso é muito comum o pessoal faz errado e acha que está fazendo certo)
1 Nota Fiscal tem no minimo 1 ou vários itens (é obrigatório pelo menos 1 item para que essa nota fiscal tenha validade) dentro de uma item é composto por 1 produto (ou depende um serviço etc, etc, etc) então um item na verdade corresponde a um produto na minha experiência e isso é a mesma coisa.
Então, 1 Nota Fiscal é composta por Item/Produto/Serviços (depende do tipo do item) e eu não vejo necessidade de uma relação N Item para M Nota Fiscal.
Pelo que eu vi no seu Diagrama:
orcamento (é a cabeça da nota)
orcamento_has_item (é composta pelo id do orcamento e id do item, mas, deveria ter uma chave primária e não ter essa chave primária composta, mesmo que isso talvez para alguns seja válida eu acredito que cada item de um orçamento tenha que ter a sua chave primária auto incremento)
-
orcamento1 x Norcamento_has_item
além disso como foi dito dentro de orcamento tem o id do cliente e
dentro do orcamento_has_item tem o id do orcamento e o id do item (que algum tipo de produto/item/serviço).
Ai vamos no que ele quer fazer e perguntado, e eu disse a minha experiência aliada com minha opinião, ele e ninguém é obrigado a aceitar o que eu aprendi e o que eu já fiz em clientes, só mesmo foi para responder a ideia dele.
E ainda acho que é gambiarra se continuar assim principalmente para exclusão de itens, sem chave auto incremento etc, mas, o principal é a análise que está errada.
- Livros e Autor tem relacionamento N:M
- Pessoas e Telefones tem relacionamento N:M (sabe porque, porque pessoas moram na mesma casa tem o menos número de telefone) e muitos fazem 1 para N e não analisam a parte do conceito da vida real.
Não quis dizer colunas distintas e relação muitos para muitos eu quis dizer no âmbito do que ele está fazendo errado, ter um relacionamento N:M com campos adicionais, não é errado, mas, fazer um relacionamento N:M sem necessidade é errado. Não vejo necessidade em fazer esse tipo de relacionamento, porque 1 Orçamento tem vários Items orçados, então 1 Para N.
Essa opinião mediante experiência foi a minha resposta, não quer dizer que você tenha que pensar igual a mim e fazer e você pode ter a sua experiência e resposta também normal.
1 curtida
Entendi, só queria ver o seu ponto de vista sobre o contexto, agora ficou mais claro sua ideia.
Eu interpretei de forma diferente, no meu entendimento faria sentido a relação N x N, pensando pelo seguinte:
Orçamento que seria a tabela principal do contexto.
Item que nesse caso representa produto.
Logo:
1 orçamento pode conter 1 ou N itens.
1 mesmo item pode existir em 1 ou N orçamentos.
Assim originando a terceira tabela orçamento_item.
1 curtida
Isso foi oque levamos em consideração na hora de gerar essa terceira tabela
Na minha concepção você pode fazer desta forma tranquilamente!
Um ponto importante a se pensar é talvez um número sequencial nessa tabela, para caso houver ocorrência de mais de um mesmo produto com valores diferentes, não sei se seu cenário tem essa necessidade, fica aí a ideia.