Иван Филатов

1. Если выбрать путь ячейки с массивом ключей - то будет блокировка обновления записи, через Concurrency Token или через какой другой механизм. Но если у вас реализована очередь (EventBus, Rabbit) то конкуренции не будет.
Еще проблема - JOIN таблиц, построение сложных запросов. Т.к. индексировать вашу ячейку сериализованную проблематично - то при запросах будет SCAN - производительность упадет на больших объемах.

2. Промежуточная таблица дает возможность параллельно работать с Производителями и Поставщиками, связывать из без конфликта конкурентной записи.
Запросы отлично выполняются, т.к. ключи индексы.

Еще изучите предметную область. Скорее всего связь между Поставщиком и Производителем - это некий Договор или Акт или какой другой бизнес объект, на основе чего вы вдруг решили связать их.
Так вот, эта связывающая сущность - это будет бизнес объект, а не просто промежуточная таблица.

SELECT M.surname, M.name FROM gazeta.tbl_gazeta_members as M
JOIN gazeta.tbl_gazeta_members_phone as P ON P.id = M.iden
WHERE P.phone LIKE '%некий номер телефона%';

разберитесь в предметной области (уничерситеты-факультеты) вначале - а потом приступайте к созданию таблиц в БД. в предметной области должна быть четкие условия существования одних факультетов в разных университетах.
хотя в жизни таких не встречал.

обычно Университеты (1 - *) Факультеты (1 - *) Специальности (1 - *) Группы

а вот Студенты могут учиться в нескольких группах, поэтому будет так - Группы (1 - *) (* - 1) Студенты.