Может там массивы с idшниками в столбцах лежат.

А как он поможет

Может outer с поиском null

Если нет null то собрали все

Left, зачем outer?

Да, left

А зачем вообще джойн, если много ко многим по требуемым таблицам?

Таблицу связи обсчитать по условию

Так многие ко многим у ачивок и пользователей. Фильтр по пользователю есть. Поэтому остаются только ачивки в какойто компании и все ачивки пользователя. Надо теперь узнать входит ли множество ачивок компании в множество ачивок пользователя.

Зависит от структуры таблиц. Так то быстрее того же join можно было бы сделать select из таблицы ачивок where not exists (select ачивок для пользователя)

А можно тогда полный текст задачи и примеры таблиц?

Вы писали изначально другие требования

Чтобы просто узнать получил ли пользователь всё ачивки или не все достаточно найти одну любую, которой у него нет. Незачем всё подмножество сравнивать.

Если использовать строгие определения (Дейт сотоварищи) — не соответствует, конечно, т.к. это вообще не отношения (есть NULL-able атрибуты). Но даже если нет — чтобы сказать, соответствует ли какая-то схема нормальной форме, нужно знать ограничения (constraints) в моделируемой области (для 3NF — функциональные зависимости), которые знаете только Вы, поэтому подобные вопросы, в общем, бесполезно задавать — разве что Вы ожидаете, что мы все эти ФЗ обязаны угадать. :)

Ну а как это сделать. Есть два списка id. Один те что в компании. Второй что у пользователя. Тут либо итерироваться по первому и проверять что кто-то не попал во второй. Либо проверить вхождение множества.

Ещё разница можно найти.

Теперь надо перевести это на sql

BTW, хочу дать совет.
Всегда используйте для полей с числовыми idшниками только bigint и bigserial.
Очень неприколько когда они заканчиваются на боевой системе, знаете ли.

Вам не кажется, что это крутовато? Есть много (довольно очевидных) ситуаций, где int на практике хватит "навсегда" — поставщики, клиенты, сотрудники и т.д. и т.п.

И да, если речь о чём-то медицинском, то пол в varchar(6) хранить незачем - там всего два варианта. Заодно вопрос с языковыми различиями обозначений снимается.
А если о чём-то околосоциальном, то в наши времена varchar(6) под "Трансгендерный олень-бисексуал" может и не хватить.