В чем нарушение синтаксиса в данном запросе? Как его исправить?
дана вот такая задача
"Добавить отзыв с рейтингом 5 на жилье, находящиеся по адресу "11218, Friel Place, New York", от имени "George Clooney""
Сделала вот такой вот cte:
WITH Reservation_gc AS(
SELECT *
FROM Reservations
WHERE user_id = (
SELECT id
FROM Users
WHERE name = 'George Clooney'
)
AND room_id = (
SELECT id
FROM Rooms
WHERE address = '11218, Friel Place, New York'
)
);
он нормально работает.
после него я могу из него получать данные. Но когда пишу:
INSERT INTO Reviews (id, reservation_id, rating)
SELECT COUNT(*) + 1, (SELECT id FROM Reservation_gc), 5 FROM Reviews
или
INSERT INTO Reviews (id, reservation_id, rating)
VALUES((SELECT COUNT(*) + 1 FROM Reviews), (SELECT id FROM Reservation_gc), 5)
или
INSERT INTO Reviews (id, reservation_id, rating)
SET id = (SELECT COUNT(*) + 1 FROM Reviews),
reservation_id = (SELECT id FROM Reservation_gc),
rating = 5
получаю такую ошибку
"ER_PARSE_ERROR: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '; INSERT INTO Reviews (id, reservation_id, rating) SET id = (SELECT COUNT(*) + 1' at line 14"
Только прохожу эту тему, в предыдущих задачах все получалось
В чем ошибка?
mysql исторически приводит в синтаксической ошибке место после которого парсер перестал понимать что происходит. При том, что весьма примечательно, это оказался символ окончания запроса ;
Смотрите на предшествующий текст запросов. Или приведите в вопросе реальный запрос, который даёт такую ошибку.
INSERT INTO Reviews (rating, reservation_id) VALUES (5,
SELECT id FROM Reservations
WHERE user_id = (SELECT id FROM Users WHERE name = 'George Clooney')
AND room_id = (SELECT id FROM Rooms WHERE address = '11218, Friel Place, New York')
)
И забудьте про SELECT COUNT(*) + 1. Это стрельба себе в ногу на поражение. прочитайте для чего служат уникальные идентификаторы и как ими пользоваться.
Melkij, Это и был реальный, просто по частям. что с ; , что без нее результат один.
Просто не понимаю почему здесь не получается сделать подзапрос отдельно в виде cte -
мне понравилась идея делать обширные подзапросы отдельно, а тут не получается.
Если его пихнуть сразу во вставку, то нормально все работает
Добавлю пять копеек. Если в этой системе один человек (или тёзки) зарезервирует на своё имя сразу две комнаты (например, на разное время), то в cte будут выбраны две строки и будет ошибка неоднозначности в SELECT id FROM Reservation_gc
дана вот такая задача
"Добавить отзыв с рейтингом 5 на жилье, находящиеся по адресу "11218, Friel Place, New York", от имени "George Clooney""
Это должно быть вот так:
INSERT INTO Reviews (user_id, reservation_id, rating)
SELECT Users.id, Rooms.id, 5
FROM Users
CROSS JOIN Rooms
WHERE users.name = 'George Clooney'
AND Rooms.address = '11218, Friel Place, New York';
А за каким рожном тут таблица Reservations, я вообще не понял. Задание про необходимость резервирования этого жилья за этим юзером не говорит ничего - то есть такого резервирования может и не быть.
За таким, что по логике Джордж Клуни может оставить отзыв о жилье только если он его бронировал, а не просто с улицы пришёл. И отзыв будет привязан к конкретной брони. Из которой уже можно получить и пользователя, и жильё. А нет брони - нет и отзыва.
Соответственно, user_id здесь избыточно, поскольку оно уже есть в таблице бронирования. Как и номер комнаты.
То есть задача именно по жилью и юзеру найти бронь, и подставить её в отзыв.
Впрочем соглашусь, что в вопросе ничего этого нет.
по логике Джордж Клуни может оставить отзыв о жилье только если он его бронировал, а не просто с улицы пришёл.
Ой, где логика и где учебные задания! Всё, что не описано явно, может быть как угодно. "Пришёл, посмотрел, сплошной срач, бронировать не стал, пишу кляузу" - чем не вариант?
А почему CROSS, а не INNER?
Так таблицы юзеров и жилья как бы не связаны - вообще никак. Отсюда и независимость, то есть CROSS JOIN. Обрати внимание - в условиях отбора нет условия, обращающегося к полям обеих таблиц. Нет, возможны и отдельные подзапросы в списке вывода, причём сервер скорее всего построит тот же самый план, но как по мне, так получается более понятный SQL-текст.
Простой
