Ограничить иерархические данные + отображение в группах

Question

У меня есть "иерархическая" структура таблицы, подобная этой:

city { id (PK), name }
place { id (PK), city_id (FK), zip_code, street }
data { id (PK), place_id (FK), x, y, z, ... }

Это должно отображаться на такой веб-странице:

city_1
  |
  |-- place_1: zip_code, street
  |      |
  |      |-- x, y, z, ...
  |      |-- x, y, z, ...
  |
  |-- place_2: zip_code, street
  |      |
  |      |-- x, y, z, ...
  |      |-- x, y, z, ...
  |
city_2
  |
  |-- place_3: zip_code, street
  |      |
  |      |-- x, y, z, ...
  |      |-- x, y, z, ...
  |
  |-- place_4: zip_code, street
  |      |
  |      |-- x, y, z, ...
  |      |-- x, y, z, ...
  |
 ...

В настоящее время это решается путем группировки данных вручную в модели:

cities = query_cities()
foreach (cities as city) {
    display_city(city)

    places = query_places(city)
    foreach (places as place) {
        display_place(place)

        datas = query_datas(place)
        foreach (datas as data) {
            display_data(data)
        }
    }
}

Я также должен предоставить функциональность фильтрации (она уже реализована), поэтому мы можем фильтровать, например. place_2, тогда будет отображаться только city_1 > place_2 > data....

Проблема в том, что список должен быть ограничен, например. отображать только первые 20 строк данных Это связано с тем, что мы работаем с довольно большим набором данных, поэтому мы должны обеспечить загрузку данных по типу Facebook. Поэтому, когда пользователи прокручивают страницу вниз, будет запрашиваться больше данных и добавляться на страницу (с помощью ajax).

Однако «почти невозможно» реализовать эту функциональность в текущей версии (было бы очень сложно отследить, где мы прервали цикл, и продолжим оттуда в следующий раз).

Я подумал, что было бы лучше решить эту проблему с помощью правильного запроса SQL. Моя первая идея состояла в том, чтобы я мог union все необходимые таблицы, чтобы их можно было легко ограничить. Однако было бы сложно (э) визуализировать результат, поскольку данные будут представлять собой единый список комбинированных данных. Кроме того, размер будет намного больше из-за дублированных столбцов данных.

Есть ли лучшее решение для решения этой проблемы с использованием реляционной базы данных (точнее, MySQL)?