Чем меньше храните - тем проще будет что-то переделать.
Чем больше храните - тем меньше логики для генерации полного урла.
Мне кажется лучше всего хранить или только навание файла или название файла + название сгенерированных директорий (если изображения шардятся по папкам 01/some_img.jpg).
Редис совсем не годится для этой задачи. Он больше подходит для хранения "горячих данных", т.к. весь набор данных он хранит в ОП (с возможностью сохранения снимка на диске). Для большого объема редко используемых данных подойдет что-то типа PostgreSQL или множество других персистентых хранилищ данных.
Очевидно что это работа с множествами (комбинаторика) - их пересечение, объединение, разность и тд - все это широко встречается в БД. Также математическая логика.
Учите лучше SQL, а не phpMyAdmin - будет больше пользы и понимания.
Если у вас уже есть MongoDB, то я бы не стал переносить предложенные штуки на эластик. При правильно настроенных индексах монга достаточно быстро работает. А так у вас будет только усложнение без особого смысла, да и в случае чего можно будет тот же эластик заменить, например, на сфинкс и переписать только логику поиска по запросу.
Если нужно иметь возможность задания разного набора характеристик для разных категорий товаров и эти категории добавляются динамически (например, в админке), то можно посмотреть EAV. Однако в этом случае вероятно использование NoSQL будет разумнее.
Ну так вы бы сразу написали, что это MongoDB. В нем нет такого понятия как таблица, есть коллекции.
Т.к. в MongoDB отсутствует формальная схема, то можно просто в коде сформировать нужные типы, данные к каждому из них и записывать все это дело в отдельную коллекцию. Единственное, тип хранить всегда в одном и том же поле и повесить на него индекс.