Мои друзья и я выполняем наш дипломный проект, и наша идея заключается в том, что если кто-то хочет go из пункта А в пункт В, мы дадим ему то, на чем он может ездить, используя публичные перевозки c (включая метро) в зависимости от критерии, выбранные пользователем (наименьшее количество транспорта, наименьшая стоимость ... et c). Мы делаем это, потому что там, где мы живем (Египет), на картах Google такой опции нет, и это наиболее полезно здесь, если у вас есть машина, и есть много общедоступных c транспортных автобусов, о которых Google ничего не знает. У нас есть данные о каждом номере автобуса и о линии автобуса, о метро, о линии метро (у нас есть 3 главных линии) и о том, на каких линиях находится каждая станция. Мы столкнулись с проблемой сопоставления имеющихся у нас данных и способа запуска нашего приложения. Наша проблема сейчас в том, что мы не уверены, какой дизайн жизнеспособен между двумя проектами, поскольку мы думали об одной из двух диаграмм:
1) Первый вариант, как на первой диаграмме , отображает ее что пользователь ищет маршрут, и таблица маршрутов будет иметь решения / опции, поэтому, например, если пользователь хочет go из точки А в точку BI, ему предложат сесть на автобус № 123, затем на второй автобус и и так далее.
2) Второй вариант, как показано на второй диаграмме , должен иметь 4 таблицы, и мы удалим таблицу маршрутов:
subway: будет иметь номер линии
станции метро: будет иметь название станции и номер линии в качестве внешнего ключа
bus: будет иметь номер шины и ее стоимость, а также
автобусная станция: будет иметь номер шины в качестве внешнего ключа и имя станции. Проблема с первой опцией состоит в том, как сохранить маршрут или вариант решения в этой таблице (маршрут). Проблема со второй опцией заключается в том, что ser хочет go из точки A в точку X, но нет ничего прямого, и ему нужно go от A до B, затем от B до X
Для технологии мы хотели использовать реагировать нативно, SQLite, node.js и, возможно, Firebase.