[RESOLVIDO] Dúvida sobre Tabela N pra N

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)

  • orcamento 1 x N orcamento_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.