Как спроектировать схему базы данных запросов автобусной станции?

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

Например, пользователь пытается получить предложение линии автобуса от станции 1 до станции 2.

Если есть автобусная линия, которая может покрыть и то, station1и другое station2, эта линия должна быть возвращена. Результат может выглядеть так:

Step1: station1 -- station2

Если между станцией 1 и станцией 2 нет прямой линии шины, то приложение должно попытаться найти план обмена, например, результат может выглядеть следующим образом:

Step1: station1 -- exchangestation

Step2: exchangestation -- station2

Теперь у нас есть данные, но мы не знаем, как спроектировать модель данных в базе данных, как создать схему, чтобы сделать запрос эффективным?

=============================================

Обновить:

Например, у меня есть четыре линии шины (фактически две), каждая из которых имеет свой цвет:

l1: A-B-C-D
l2: D-B-A (in fact, the l2 is the reverse of l1 except the l2 will skip station `C`.
l3: E-B-D-F
l4: F-D-B-E(reverse of l3) 

Теперь, если мы хотим сохранить эту информацию в базе данных, чтобы запросить план шинной линии для данной одной станции к другой, то сколько таблиц нам нужно, и что следует поместить в каждую таблицу?

Я думаю, что вам нужно создать другую таблицу, которая определяет все маршруты как комбинации других маршрутов. Затем вы запрашиваете эту таблицу и присоединяетесь к фактическим маршрутам, чтобы получить геометрию.

Если запрос «от станции» до «на станцию», и в каждом разделе есть «от станции» и «до станции» Но вы хотите включить маршруты, состоящие из нескольких разделов, у вас может быть другая таблица «маршруты», которая имеет что-то вроде:

• «название маршрута», «идентификатор маршрута», «от станции», «до станции»

вам также нужен ваш оригинальный раздел таблицы, что-то вроде:

• «имя раздела», «идентификатор раздела» и т. д.

и я думаю, что вам нужен еще один стол соединения, как:

• «идентификатор маршрута», «идентификатор раздела»

и в этой таблице хранится отношение один ко многим между таблицами маршрутов и секций, поэтому в приведенном выше примере у вас есть две строки в таблице соединений, по одной на каждый шаг. Запросы выполняются в таблице маршрутов, от и до станций. Возвращенные данные, если они пространственные, представляют собой детали из таблицы маршрутов и пространственные данные из таблицы сечений. Может быть, вы сложите время из каждого раздела или что-то еще.

Имеет ли это смысл?

Вы, вероятно, должны выбрать инструмент для этого и следовать схеме силы инструмента (например, pgRouting ).

Если вы хотите сделать это без таблицы, вам нужны только две таблицы для хранения вершин и узлов.

Хитрость в том, что ваше изображение демонстрирует пространственный подход, в то время как на самом деле вам нужен временный (изображение в ожидании). Шина не идет от узла A к узлу B. Шина идет от узла A @ 12: 00 к узлу B @ 12: 10 .

Таким образом, мы создаем узел для каждой станции + узел для каждого времени отправления с каждой станции. Каждый узел имеет 3 односторонние ссылки, выходящие из него:

• ссылка на пункт назначения автобуса (A @ 12: 00 - B @ 12: 10 стоимость: 10 минут)
• ссылка на следующий автобус, отправляющийся с этой станции (A @ 12:00 - A @ 12:30 стоимость: 30 минут)
• ссылка на базовый узел (A @ 12: 00 до A: 0 минут)

Теперь, чтобы найти соединение из точки А в точку С, мы выбираем самую раннюю точку сопоставления на станции А и находим наш путь оттуда к базовому узлу для станции С.

Узлы:

id|station|time
---------------
1 |A      |NULL
2 |B      |NULL
3 |A      |12:00
4 |B      |12:10

вершины

id|start_node|end_node|line|cost
---------------------------
1 |3         |4       |l1  |10
2 |3         |1       |NULL|0
3 |4         |2       |NULL|0

Вот рабочий пример использования javascript и данных из OpenStreetMap. Модель данных может быть полезной.