У меня есть 3 таблицы:
events
+--------------------------------+
| id | date | Name |
+--------------------------------+
| 1 | 2019-09-29 | First Event |
| 2 | 2019-10-05 | Second Event |
| 3 | 2019-10-11 | Third Event |
+--------------------------------+
files
+-----------------------------+
| id | name | fileSize |
+-----------------------------+
| 1 | 1 file name | 1234786 |
| 2 | 2 file name | 6127833 |
| 3 | 3 file name | 1207834 |
| 4 | 4 file name | 2912873 |
| 5 | 5 file name | 7893465 |
+-----------------------------+
agendaItems
+-----------------------+
| id | eventId | fildId |
+-----------------------+
| 1 | 1 | 1 |
| 2 | 1 | 4 |
| 3 | 1 | 2 |
| 4 | 1 | 5 |
| 5 | 1 | 1 |
| 6 | 2 | 3 |
| 7 | 2 | 4 |
| 8 | 2 | 3 |
| 9 | 2 | 3 |
| 10 | 2 | 2 |
| 11 | 3 | 1 |
| 12 | 3 | 3 |
| 13 | 3 | 5 |
| 14 | 3 | 4 |
| 15 | 3 | 1 |
| 16 | 2 | 2 |
| 17 | 1 | 3 |
| 18 | 3 | 4 |
+-----------------------+
Если пользователь ищет в файлах строку файл и возвращает 5 файлов, как мне также показать последнее событие (идентификатор / дата)/ name), частью которого был каждый файл, а также вся информация о файле?
Я занимаюсь этим часами и, похоже, не могу найти решение без подзапросов уровня 3. Если я присоединяюсь к элементам повестки дня и событиям с помощью GROUP BY, затем выбираю MAX (events.date), я могу получить правильную дату, но имя и идентификатор не всегда правильны ...
Проблема, как представляется, заключается в том, что существуетне прямая связь между файлами и событиями, поскольку один файл может быть добавлен к нескольким элементам повестки дня внутри события (например, файл 1 находится в событие 1 дважды в повестки дня 1 &5 ). Все остальные посты, которые я видел здесь, не подходят для этой ситуации.
Мне кажется, что я здесь упускаю что-то действительно очевидное. Любая помощь была бы великолепна.
Редактировать 1: До сих пор моим решением было создание подзапроса для получения всех событий, частью которых являлся каждый файл, я мог затем выбрать из этого, чтобы получитьMAX (events.date) для каждого файла, а затем их оставляют присоединенными к основному запросу, который получает информацию о файле.
Но это кажется действительно неэффективным, особенно в долгосрочной перспективе. В будущем мне пришлось бы выбирать потенциально много-много тысяч комбинаций файлов / событий каждый раз, чтобы получить последний раз, когда 5 файлов были частью событий.