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?
Estou com uma dúvida na seguinte ligação N
para N
.
orcamento_has_item
?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.
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.
Considerando esse seu exemplo, no caso é o mesmo que fiz na tabela orcamento_has_item, porém com um nome diferente, estou certo ?
Também não entendi, é muito comum.
Também não entendi, é muito comum.
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.
Só por curiosidade, porquê você acha que ter colunas distintas em uma tabela resultante de uma relação N x N é gambiarra?
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.
Só por curiosidade, porquê você acha que ter colunas distintas em uma tabela resultante de uma relação N x N é gambiarra?
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.
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 orçamento pode conter 1 ou N itens.
1 mesmo item pode existir em 1 ou N orçamentos.
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.