В БД есть таблицы отделы и сотрудники. Каждый сотрудник может состоять в 1 или 2ух отделах, но не более.

Как бы нельзя быть немножно беременной. Либо 0, либо 1, всё, что больше -- много.
Надо делать таблицу. Если ты её не сделаешь -- у тебя в таблице будет нарушение 1НФ, что вообще фатальная ситуация.
Так что делай, а когда у тебя вдруг окажется, что какой-то сотрудник должен в 3-х отделах работать, совершенно внезапно,
твоя БД и это сможет хранить.

Как "правильно" с практической точки зрения реализовать связи между этими таблицами? Обязательно ли в таком случае организовывать связь многие ко многим через промежуточную таблицу?

Ещё раз, связи либо 1:0..1, либо 1:M, либо M:N (многие ко многим).

1:0..1, либо 1:M -- это ссылка из одной таблицы на другую, поле в дочерней таблице.
M:N (многие ко многим) -- промежуточная таблица.
Третьего не существует.

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

Этот бред я не понял.

Просто, хочется минимизировать количество таблиц в БД.

Это самая глупая идея, которая только может прийти в голову проектировщику БД -- экономить таблицы.

Однако, может подскажете ещё, как "покрасивше" реализовать запрос с промежуточной таблицей (или где почитать об этом)?
Пока, только так получается:


Я не понял, где запрос ?
И чем он тебе не нравится -- не забудь добавить.

Torrero11А хотелось бы, чтобы значения не повторялись и было 3 столбца: Отдел1, Отдел2, Фио.

Это нарушение 1НФ, тяжкий грех для любого разработчика РБД.
А как раз что строки с сотрудником повторяются -- правильно.
Если тебе не нравится -- можешь вывести отделы сотрудников отдельным набором данных.

Кот МатроскинTorrero11А хотелось бы, чтобы значения не повторялись и было 3 столбца: Отдел1, Отдел2, Фио.

Это довольно легко сделать запросом по данной структуре

Это не нужно делать запросом. Это -- самое главное.

Torrero11 отделы сотрудников отдельным набором данных следует делать на клиентской стороне?

Да как хочешь.

Кот МатроскинЭто не нужно делать запросом. Это -- самое главное.
А как же это надо делать, если не запросом ? :)


Давай вернёмся к началу, будем плясать от печки.

ЧТО нам нужно сделать, сформулируй полностью.