Запрос для вывода таблицы в DBGrid

[BattlePingvin]

Помогите пожалуйста доработать запрос, надо вывести таблицу в DBGrid.
Поля таблицы:
Код спектакля
Название спектакля
Автор
Жанр
Тип спектакля
Бюджет спектакля
Режиссер постановщик
Художник постановщик
Дирижер постановщик

Проблема с получением данных из трёх последних полей - постановщики, все три поля связанны с одним кодом из другой таблице - Код работника который находится в таблице Работники, и надо выводить не значение кода, а ФИО из таблицы Работники которое соответствует этому значению, подскажите как это можно реализовать в одном запросе ?
Вот мой код на получения данных из остальных полей:

SELECT Спектакли.[Название спектакля], Авторы.ФИО AS Автор, Жанры.Жанр, Спектакли.[Театр первой постановки], Спектакли.[Год первой постановки], Спектакли.[Бюджет спектакля], [Типы спектаклей].[Тип спектакля]
FROM Авторы INNER JOIN ([Типы спектаклей] INNER JOIN (Жанры INNER JOIN Спектакли ON Жанры.[Код жанра]=Спектакли.Жанр) ON [Типы спектаклей].[Код типа]=Спектакли.[Тип спектакля]) ON Авторы.[Код автора]=Спектакли.Автор;

[mansuetudo]

Т.е. в этих полях стоят коды работника? Тогда я бы писала что-то вроде

select k.[ФИО работника] 
from Работники k, <имя таблицы с кодами режиссёра, художника, дирижёра> t
where t.[код работника]=k.[код работника]

Кстати, выборку из других таблиц я предлагаю тоже делать аналогичным образом, т.е. определить, по каким полям таблицы между собой связаны, и по ним составлять условие и таким образом всё увязать в один запрос. Если бы вы описали структуру таблиц, было бы легче дать конкретный ответ.

[Прик]

Автор темы явно лукавит. Не вызывало же у него затруднений при объединении таблиц Автор, Жанр, Тип...
Хотя, если речь о проблеме с одной и той же таблицей для объединения из разных ее строк, то проблема решается алиасами (псевдонимами) таблицы Работники.
Типа: Работники as Реж JOIN ... Реж.ФИО ... Работники Худ JOIN ... Худ.ФИО... и т.д.

PS. 2 mansuetudo. Неявное объединение (по условиям в where) давно отжило свое. И дело здесь не в том., что это "неправильно", а в том, что все сервера СУБД (в т.ч. и микрософтовские) оптимизирует производительность запроса по явному объединению (через join).

[Аватар]

Прицепите JOIN-ы к Спектакли согласно правил СУБД примерно так:

LEFT JOIN Работники R1 ON R1.Kod=Спектакли.[Режиссер постановщик]
LEFT JOIN Работники R2 ON R2.Kod=Спектакли.[Художник постановщик]
LEFT JOIN Работники R3 ON R3.Kod=Спектакли.[Дирижер постановщик]

и в SELECT-е:

R1.[ФИО работника] AS Fio1,R2.[ФИО работника] AS Fio2,R3.[ФИО работника] AS Fio3

[Sparky]

Согласна с Прик, связь через where устарела и уже давно доказано что она не эффективна, все довольно хорошо всегда можно сделать через различные join

[Аватар]

Сообщение от Прик

все сервера СУБД (в т.ч. и микрософтовские) оптимизирует производительность запроса по явному объединению (через join).

Интересно бы было посмотреть на источник такой информации

[Sparky]

Аватар, встречала это во многих книгах, последние были по ораклу

[mansuetudo]

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

[Аватар]

Сообщение от Sparky

Аватар, встречала это во многих книгах, последние были по ораклу

Будет свободное время поэксперементирую с планами запросов на MSSQL. Мучает сомнение, что это так.

[Serge_Bliznykov]

Будет свободное время поэксперементирую с планами запросов на MSSQL. Мучает сомнение, что это так.

аналогично.
я более чем уверен, что where и join'ы преобразовываются в один и тот же внутренний запрос...
Буду признателен, если кто-то фактами подтвердит или опровергнет данный постулат. (неплохо бы и для разных СУБД)


p.s. думаю, что будет уместным не продолжать обсуждение в данной теме, а создать новую тему для обсуждения данной проблемы.