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

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

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 ?

>

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**,

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).