LEFT JOIN com operador IN (1,2,4,5,7)

[Didyo 1]

Olá pessoal, não sei se é possível mas minha ideia seria usar o operador IN dentro de um JOIN 
substituindo o "=".
Ex: Teria uma tabela itens_cardapio (car_id, car_nome, car_bebidas)
e outra tabela > bebidas (b_id, b_nome)

Sei que poderia relaciona n:m tendo uma tabela tipo itens_cardapio_has_bebidas (fk_car_id, fk_b_id) porém queria fazer diferente pois para o que quero isso geraria muitas linhas na tabela de junção.

Gostaria que o campo car_bebidas na 1ª tabela armazenasse os ids das bebidas da 2ª tabela. Ex. car_bebidas=1,2,5,6,9,11
e na consulta ficaria algo do tipo:
SELECT i.* , GROUP_CONCAT(b.b_nome) FROM itens_cardapio i 
INNER JOIN bebidas b ON (b.b_id IN i.car_bebidas)

Tentei também algo tipo 

SELECT i.* , (SELECT b.nome FROM bebidas b WHERE b.b_id IN i.car_bebidas) FROM itens_cardapio i 

Usei algumas variação com GROUP BY e GROUP_CONCAT,...

Consegui obter resultados como:
- a primeira bebida de cada item do cardápio
- repetir várias vezes cada bebida por item,
e outros, mas nenhum 100% correto.

Se no IN usar os números dos ids das bebidas manualmente, ao invés de puxar de um campo, ele busca as bebidas pedidas,
porém não fica dinâmico, pois é sempre os mesmos números de modo a todos itens do cardápio ficaram com (coca-cola,sprite,fanta) por exemplo.

Se tiverem alguma ideia agradeço.

[Didyo 1]

Olá pessoal, consegui solucionar o problema de 2 formas.

Minha ideia era relacionar 2 tabelas de um cardápio, exemplo (itens e bebidas) sem usar relacionamento n:m, mas armazenando os ids das bebidas em um campo "lista_bebidas".

 

Para quem desejar,  ao invés de usar o operador IN no JOIN ON,
basta usar o FIND_IN_SET com GROUP_CONCAT e GROUP BY
para agrupar os resultados por linha.

 

Tabela cardapio_itens (* apenas demonstrativo)

id  ||    item_nome    ||   lista_bebidas 

1   ||     refri 300ml    ||  1,2,4,5

2   ||     refri 600ml    ||  2,3,5

 

Tabela cardapio_bebidas (* apenas demonstrativo)

 id ||    nome_bebida  

1   ||   cola

2   ||   guaraná

3   ||   uva

4   ||   laranja

5   ||   limão

 

Solução 1 - com uso de JOIN: (minha preferida)

SELECT i.*, GROUP_CONCAT(b.nome_bebida) as bebidas FROM cardapio_itens i 

LEFT JOIN cardapio_bebidas b ON FIND_IN_SET(b.id, i.lista_bebidas) 

GROUP BY i.id       

 

Resultado:

1   ||    refri 300ml    ||     cola, guaraná, laranja, limão

2   ||    refri 600ml    ||     guaraná, uva, limão  

 

Solução 2 - com uso de Subquery: 

SELECT i.*, (SELECT GROUP_CONCAT(b.nome_bebida) as bebidas FROM cardapio_bebidas b WHERE  FIND_IN_SET(b.id, i.lista_bebidas)  ORDER BY b.nome_bebida ASC)   FROM cardapio_itens i 

 

Essa escolha foi para evitar um grande número de linhas em uma tabela de ligação n:m, devido a serem vários restaurantes e bares com várias bebidas em tamanhos diferentes.

Sei que para uma questão de integridade,... a melhor opção seria a terceira tabela n:m. Se o esperado fosse apenas alguns milhares de linhas até usaria n:m com uma tabela de junção itens_has_bebidas.

 

Obrigado a todos

[Bergs 53]

 

lista_bebidas  passou a ser uma chave estrangeira?

 

Se você deletar um item como limão por exemplo isso seria fácil de atualizar em todos os registros de refri na tabela cardapio_itens ?

 

 

[Didyo 1]

4 horas atrás, Bergs disse:

 

lista_bebidas  passou a ser uma chave estrangeira?

 

Se você deletar um item como limão por exemplo isso seria fácil de atualizar em todos os registros de refri na tabela cardapio_itens ?

 

 

Olá Bergs, nesse caso específico não usei como chave estrangeira. A necessidade e objetivo são outros.
Sei que se usa-se n:m seria mais prático e fácil de garantir a integridade.  

 

No exemplo que usei, é claro que se limão tiver escrito errado (lemãoo) na tabela cardapio_bebidas e for corrigido (UPDATE),
automaticamente a correção afetará todas as linhas que tenham limão em cardapio_itens.
pois nessa tabela, embora em um único campo, estão armazenados apenas os IDs das bebidas.

 

Também seria importante cuidar para não permitir que limão seja removido da tabela cardapio_bebidas 
caso esteja em alguma linha em cardapio_itens.

Poderia usar uma TRIGGER com uma validação antes de a linha ser removida (BEFORE DELETE).

Use um campo (quantidade) para controlar quantos itens usam a bebida limão e só permita que seja removida caso a quantidade seja 0;

 

Se desejar que quando nenhum cliente possuir mais a bebida limão,
a mesma seja removida da lista em cardapio_bebidas, 
poderia usar um campo quantidade (qnt) na tabela cardapio_bebidas
e usar UPDATE quando a bebida é inserida ou removida em cardapio_itens.

Depois, se a quantidade for 0, você pode remover a bebida da lista.

Para otimizar esses processos poderia usar TRIGGER no UPDATE da tabela cardapio_bebidas, 
onde, quando qnt=0 , DELETE. 

 

Na situação que estou usando, em (cardapio_bebidas) um usuário não poderá excluir uma bebida (exemplo: limão),

pois a mesma poderá estar sendo usada por outros restaurantes e bares.

Esta tabela apenas armazena todas opções disponíveis de bebidas

sendo que o usuário pode apenas incluir novas bebidas, sendo que cada bebida é única UNIQUE.

 

No entanto o usuário pode remover a bebida limão de sua lista de bebidas (cola, limão, laranja)  que está armazenada apenas os ids (1,3,4) das mesmas em um campo na tabela cardapio_itens.  Mas lembrando, limão não será removido da tabela cardapio_bebidas pois outros usuários poderão ter essa bebida.

 

No meu caso não deverá haver a necessidade de excluir uma bebida se a quantidade for 0,
apenas se ela não existir ou se o nome estiver escrito errado. 

 

Isso porque serão armazenadas as principais marcas com suas variações (coca-cola, pepsi, coca-cola zero,...)  em torno de 40 no máximo 60 registros 
e no caso das demais marcas serão armazenadas apenas os sabores (limão, guaraná, limão zero, laranja,...) em torno de mais uns 50 registros. Total uns 100 registros apenas. 

 

Mesmo se colocar todos refrigerantes com marca e sabor  seria no máximo 300 a 400 registros. 

Vamos supor que dê 5 ou 10 Mil registros incluindo cervejas, vinhos, espumantes,...  
Não acredito que manter tais registro apenas para consulta irá prejudicar muito o banco de dados pois usam indÍces (PRIMARI KEY).