Это самое странное утверждение JOIN, которое я когда-либо видел. Вот ваш запрос, преобразованный в синтаксис ANSI-89:
SELECT e.entertainerid,
e.firstname,
e.lastname,
b.customerid,
b.eventdate,
bd.category,
bd.duration,
s.specialitydescription,
es.entertainerspecialitycost
FROM Entertainer e,
BookingDetail bd,
Booking b,
EntertainerSpeciality es,
Speciality s
WHERE e.entertainerid = bd.entertainerid
AND b.bookingid = bd.bookingid
AND e.entertainerid = es.entertainerid
AND s.specialityid = es.specialityid
AND e.entertainerid = [Enter EntertainerID]
Здесь ваш исходный запрос с очищенным синтаксисом - это должно помочь упростить просмотр общей информации:
SELECT e.entertainerid,
e.firstname,
e.lastname,
b.customerid,
b.eventdate,
bd.category,
bd.duration,
s.specialitydescription,
es.entertainerspecialitycost
FROM ENTERTAINER e
JOIN BOOKINGDETAIL bd ON bd.entertainerid = e.entertainerid
JOIN BOOKING b ON b.bookingid = bd.bookingid
JOIN ENTERTAINERSPECIALITY es ON es.entertainerid = e.entertainerid
JOIN SPECIALITY s ON s.specialityid = es.specialityid
WHERE e.entertainerid = ?
Разница заключается в том, что синтаксис ANSI-89 включает критерии объединения в предложении WHERE
, а также фактические критерии фильтрации. Чтобы выделить ANSI-92:
FROM ENTERTAINER e
JOIN BOOKINGDETAIL bd ON bd.entertainerid = e.entertainerid
... против ANSI-89:
FROM ENTERTAINER e,
BOOKINGDETAIL bd
,... -- omitted for purpose of example
WHERE e.entertainerid = bd.entertainerid
Синтаксис ANSI-92 является предпочтительным:
- ANSI-89 не имел последовательно реализованного синтаксиса LEFT JOIN в различных базах данных, поэтому операторы были такими переносимыми
- ANSI-92 обеспечивает более мощные соединения (т. Е. X ON x.id = y.id И x.col НЕДЕЙСТВИТЕЛЕН)
- ANSI-92 легче читать, отделяя критерии объединения от фактических критериев фильтра