Как мне создать прерывистый через точки для маршрута путешествия - PullRequest
Новая
       27

Как мне создать прерывистый через точки для маршрута путешествия

1 голос
/ 26 января 2012

Я пытаюсь спроектировать бэкэнд и у меня есть следующий вариант использования.

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

Я пытаюсь найти хороший способ справиться со случаем, когда есть остановки в пунктах.

Например, маршрут полета для A -> B на самом деле выглядит так: 

A -> C
C -> D
D -> B

поэтому A -> B - это одно целое, но, в свою очередь, оно состоит из нескольких ветвей.

Мой текущий дизайн:

Таблица AirLeg: 

- id
- departure and arrival information
- viaPoints: BOOL

Таблица viaPoints: 

- id
- airLegId // FK into Airleg table
- similar departure and arrival information from airLeg table

// если в таблице AirLeg флаг viaPoints имеет значение True, можно запросить таблицу viaPoints, используя таблицу airLegId для получения посредников.

Есть ли лучший способ справиться с этим?

Я думал, что добавлю информацию о поездке или сегменте в одну сторону:

  • AirLeg-id
  • Аэропорт вылета: FK в аэропорты
  • Аэропорт прилета: FK в аэропорты
  • Метка времени вылета (по местному времени города вылета)
  • Метка времени прибытия (по местному времени города прибытия)
  • продолжительность полетаэтот авиаперелет: статическое значение
  • flightId: FK для авиакомпаний с указанием названия авиакомпании и номера рейса
  • Правила провоза багажа: текст
  • Разное (ТЕКСТ: Политика отмены)

РЕДАКТИРОВАТЬ:

Я добавил связанный вопрос , и я думаю, что ответ на эту проблему должен удовлетворить оба требования.

Если в поездке несколько сегментов, цена определяется для всего рейса, а не для отдельных сегментов

Аналогично, цена за рейс в оба конца указывается как единица, а не отдельные компоненты из A-> Bи обратно, B-> A.

Ответы [ 2 ]

1 голос
/ 26 января 2012

Я пытаюсь соединить два вопроса, и не совсем понятно, что вы хотите сделать, - но я думаю, что это сводится к следующему.

У вас есть маршрут , который является родительским элементом.«Маршрут» состоит из нескольких частей (вопрос: хотите ли вы работать с маршрутами, состоящими из нескольких частей, например, «Лондон-> Париж-> Нью-Йорк-> Лондон»?).Маршрут имеет цену.Цена НЕ является суммой цены ног, потому что обратные поездки дешевле, чем два способа.

Itinerary
---------
ID
Price

Leg
----
Departure Airport : FK into airports
Arrival Airport : FK into airports
Departure timestamp (in departure city's local time)
Arrival timestamp (in arrival city's local time)
flight duration of this airleg: static value
flightId : FK into airlines yielding airline name and flight number
Baggage Policy : text
Misc (TEXT: Cancellation policy)

Вы можете хранить цену в отдельной таблице - но это нужно делать только в том случае, если цена изменяется независимо от маршрута (например, если цена в понедельник составляет 100 долларов, а во вторник - 200 долларов).

Я бы посоветовал вам не использовать " магические числа " в схеме базы данных - вместо того, чтобы возвращать ответвление равным -1, вы должны оставить его пустым - ответного ответвления не будет.Это делает ваш SQL намного проще для чтения и намного менее подверженным ошибкам - вы не зависите от того, что разработчики помнят, что «-1» означает, что ответного участка нет, -2 означает, что предварительно забронирован этап и т. Д.

1 голос
/ 26 января 2012

Я бы разработал это так: 

Journeys:

 - ID
 - Other info (billing, whatever)

Segments:

 - ID
 - JourneyID (FK)
 - departure, arrival, etc

И дополнительный вид 

Journeys_View

 - Journeys.*
 - First departure
 - Last arrival
...