alex-1917

Звучит как задание)))
Ну да ладно...
У вас вопрос из двух частей:
1. как сделать визуальный конструктор чего-то там - гугл трещит от готовых кусков кода.
тут даже жевать нечего, потому что вы, как и большинство начинашек, привели одну строку плюс море воды, за вас домысливать никто не будет.
напишите четко и по рунктам, может кто и разжует, а пока что и жевать нечего.

2. сформировать из сформированного юзером некоего нагромождения информации файл в pdf
есть же отличная либа tFPDF, правда по умолчанию у неё траблы с кириллицей, но решение (готовое) тоже есть.

если не справитесь, то пишите, поищу готовый код, проверен уже на 3проектах

Склеивание через джойны не поможет, у вас плоские запросы и должны работать мгновенно, профилируйте запросы по отдельности и смотрите, чо и как.
Как тут выше-ниже советуют - то на то и выходит, никакой оптимизации не будет! так как у вас результат в виде ID получается сугубо по результатам очередного запроса, то вся байда будет стоять и ждать - лучше, если эта байда будет ждать в приложении (PHP), нежели вся байда будет висеть в памяти MySQL в ожидании...
Задайте на SC, там уровень спецов ощутимо выше, в идеале если Mike ответит...

UPD. Кстати, почему для получения одного ID вы юзаете fetch_assoc?????))))

А почему плоского запроса боитесь???

SELECT g.step_id, g.name, cg.status, cg.date_added 
FROM oc_gamefication g, oc_customer_gamefication cg 
WHERE g.customer.id = 26854 AND g.id = cg.gamefication_id

Собсно вы сами и ответили.

Единственное что приходит на ум сделать триггер который будет записывать в другую таблицу кол-во или что то такого

На двух проектах была аналогичная проблемка, там в БД по 30-40млн строк.
Решено было добавлением функции типа Записал в БД1 - Запиши LastID в БД2
В итоге в БД2 было с десяток строк, в каждой свои LastID (нужна была разбивка по неким параметрам).
Ответ = 1мс!))))

Конечно, это если вам действительно нужно частое получение этого вашего Count)))

Любой движок взяли бы и посмотрели бы, зачем ВЕЛОСИПЕД изобретать?
Толковые фильтры есть и в опенкарт и в минишоп2 и в битрикс.
Везде они естественно платные....
Хотя про битрикс я наверное зря, это не ваше))))

Минишоп - бесплатно ставите пакет miniShop2 + mSearch2 на демо-серверах, изучаете.
На демке как раз как вам нужно - _minishop2.com/catalog/

Битрикс - бесплатно ставите демо-версию, ищите фильтр с бесплатной демо-установкой - всё! дальше неделю или сколько там даст разработчик фильтра - роетесь.

А вот опенкарт казалось бы бесплатный по сути, а фильтр просто так не поставить, только предоплата))

50к - мизерная выборка, забей!!))
если проект на вырост, тогда не забивай!!))

В твоем варианте смешная выборка, не видел ты 10 этажных джойнов, коллега!!...

И еще - не забывай, что БД ВСЕГДА хранится на диске, а в памяти она появляется уже потом)))! отсюда выход для некоторых огромных запросов - быстрее вопрос решается обработкой не в БД, а на приложении.
Если кратко, то делаешь выборку ВСЕХ твоих номеров без условий - для БД это самая непрожорливая операция, по сути два мгновения, далее выборку в массив и уже на сервере разбираешь чо и как, через тот же php. Проверено на выборках 20М-300М - - скорость фильтрации на два порядка больше, если это дело поручать приложению!

Да, группировка самый простой способ, другие варианты всяко прожорливее.
И кстати группировку при больших объемах можно и нужно делать не в MySQL, а в php - т.е. одним простым и быстрым запросом вытягиваешь ВСЁ в массив, далее в массиве спокойно группируешь и выводишь - тут будут использоваться уже ресурсы процессора, так разумнее, ведь редко нужно предоставлять требуемый тебе результат в течение 1 микросекунды, у тебя же не биржа с биткойнами, ну а за 1 миллисекунду любой процессор разложит массив по полочкам. будь в нем хоть миллион строк, пишу, потому что делал так, это не из гугла!!))

Довольно размытый вопрос, как следствие, не ответы, а каша.
Уточнимся - если цель - борьба с мультиакками - лучшее средство - накопительные скидки !

Учитывая три фактора:
1. Ваше заявление о том что приложение планируется маленькое
2. Такое приложение будет действительно маленьким, вы навряд ли делаете его для школы №63 в Тюмени, где в этом году набрали 26 классов, даже 1-я!))
3. Дней недели действительно всего семь, их не будет меньше, их не будет больше, считаю глупостью заводить таблицу для дней недели, тогда уж лучше создать для этого поле типа ENUM.
ТАКИ: таблица может остаться плоской и это факт.

Все остальные доводы против - вы не научитесь делать джойны и запросы к нескольким таблицам за один присест, вас не будет заботить возможность ускорения запроса через отдачу части расчетов php-интерпретатору и т.д.
Выбирайте сами)))