Looping in Union All - mysql

Question

I'm writing a stored procedure that will display yes/no counts by an alcohol category and job number. I started programming the current categories - wine, beer, whisky - via an union all but thinking ahead there might be more categories and I visualize this code getting hefty in size. Is it possible to perform a union all in a loop and then pass the alcohol category argument? Trolled the internet and have seen very little on the subject so any help or guidance will be most appreciated.
The start of my code...
delimiter $$
create procedure alc_cat_yn (in jid int)
begin
select
cast(concat(jobid,' - Wine')
as char(50)) as `Job Number - Consumed Yesterday`
,sum(case when wine_id=1 then 1 else 0 end) as y
,sum(case when wine_id=2 then 1 else 0 end) as n
from demos
where jobid=jid
group by jobid
union all
select
cast(concat(jobid,' - Beer')
as char(50)) as `Job Number - Consumed Yesterday`
,sum(case when beer_id=1 then 1 else 0 end) as y
,sum(case when beer_id=2 then 1 else 0 end) as n
from demos
where jobid=jid
group by jobid
union all
select
cast(concat(jobid,' - Whisky')
as char(50)) as `Job Number - Consumed Yesterday`
,sum(case when whisky_id=1 then 1 else 0 end) as y
,sum(case when whisky_id=2 then 1 else 0 end) as n
from demos
where jobid=jid
group by jobid;
end

Answer 1

In theory, you could have a loop which builds the query string in a loop and executes it as a prepared statement. Doing so, however, is bad practise. Instead, you should avoid having different columns for your different alcohol categories. Use a single column with multiple rows. Each row would contain the jobid, the alcohol category and a value (e.g. 1 or 2).
I'm a bit mystified why your columns are called *_id, as you seem to store some yes/no information, and not an identifier for some row in another table. You might want to choose a less misleading name.
For the category, you could either use an enum, or the name stored in a string, or a number referencing the primary key of some other table that lists your kinds. The enum will mean that every new category requires a change to the database schema. A string might consume considerable amounts of memory, particularly if you choose long names. Therefore, references to another table are the most flexible solution and probably your best choice in the long run.
You could still provide the current structure as a view, based on the extended table. If you use a new name for the restructured table, and reuse the current name for this view, then backwards compatibility with existing code could be maintained.
Little note: MySQL uses 0 or 1 to represent boolean values. So instead of writing case when foo=bar then 1 else 0 end you could simply write foo=bar. This will make your code much shorter. Otoh, it will also make it harder to read at first glance, so perhaps best place a comment somewhere about this use.