Представление данных (станции метро)

@Subway_ · Регистрация: 05.09.2016

Студворк — интернет-сервис помощи студентам

Приветствую всех!
Уже который день бьюсь над тем, как лучше представить данные - станции метрополитена (например, московского). В виде базы данных с таблицами и строками? В виде многомерного массива? В виде паскалевского типа record? Или еще как?
Чтобы эти данные включали в себя всё: все станции, указание к какой линии они принадлежат, последовательность на линии, какие станции сколько линий связывают и т.д.
Короче говоря, в каком виде план метрополитена лучше представить?

Допустим, одна таблица - список линий метро.
Вторая таблица - список станций и ссылка на линию (станция может принадлежать несколько линиям).
Третья таблица - список пересечений линий.
Непонятно, как указать направление линий и их взаимное расположение.

Спасибо за помощь в виде мыслей и советов.

@Shamil1 · 12.09.2016, 21:31

Например, в реляционной базе данных. Хотя данных мало, и данные целиком считываются в память, так что можно хранить в любом формате (csv, xml, json,...)

Линии: название, список ссылок на станции
Станции: название, ссылка на линию, порядковый номер, список ссылок на переходы (пересадки), (если нужно) координаты (на карте и/или на схеме).. Станция не может принадлежать нескольким линиям! Станции на разных линиях могут иметь одинаковое название.
Пересадки: ссылка на станцию1, ссылка на станцию2

@krapotkin · 13.09.2016, 07:12

да. это обычный граф.
храним вершины - станции, и ребра - перегоны и переходы

@Subway_ · 13.09.2016, 08:42 **[ТС]**

Сообщение от krapotkin

да. это обычный граф.
храним вершины - станции, и ребра - перегоны и переходы

а графы обычно в каком формате хранят?

@krapotkin · 13.09.2016, 10:15

таблица вершин
таблица ребер

Добавлено через 39 секунд
ребра содержат ID первой и второй вершины

Новые блоги и статьи Все статьи Все блоги /
Подстановка значения реквизита справочника в табличную часть документа Maks 10.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: при выборе сотрудника (справочник Сотрудники) в ТЧ документа. . .	Очистка реквизитов документа при копировании Maks 09.04.2026 Алгоритм из решения ниже применим как для типовых, так и для нетиповых документов на самых различных конфигурациях. Задача: при копировании документа очищать определенные реквизиты и табличную. . .	модель ЗдравоСохранения 8. Подготовка к разному выполнению заданий anaschu 08.04.2026 https:/ / github. com/ shumilovas/ med2. git main ветка * содержимое блока дэлэй из старой модели теперь внутри зайца новой модели 8ATzM_2aurI	Блокировка документа от изменений, если он открыт у другого пользователя Maks 08.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в конфигурации КА2. Задача: запретить редактирование документа, если он открыт у другого пользователя. / / . . .
Система безопасности+живучести для сервера-слоя интернета (сети). Двойная привязка. Hrethgir 08.04.2026 Далее были размышления о системе безопасности. Сообщения с наклонным текстом - мои. А как нам будет можно проверить, что ссылка наша, а не подделана хулиганами, которая выбросит на другую ветку и. . .	Модель ЗдрввоСохранения 7: больше работников, больше ресурсов. anaschu 08.04.2026 работников и заданий может быть сколько угодно, но настроено всё так, что используется пока что только 20% kYBz3eJf3jQ	Дальние перспективы сервера - слоя сети с космологическим дизайном интефейса карты и логики. Hrethgir 07.04.2026 Дальнейшее ближайшее планирование вывело к размышлениям над дальними перспективами. И вот тут может быть даже будут нужны оценки специалистов, так как в дальних перспективах всё может очень сильно. . .	Горе от ума kumehtar 07.04.2026 Эта мне ментальная установка, что вот прямо сейчас, мол, мне для полного счастья не хватает (нужное вписать), и когда я этого достигну - тогда и полный кайф. Одна из самых сильных ловушек на пути. . . .

@Subway_ 0 / 0 / 0 Регистрация: 05.09.2016 Сообщений: 8

	Представление данных (станции метро) 12.09.2016, 21:02. Показов 1326. Ответов 4 Метки нет (Все метки) Приветствую всех! Уже который день бьюсь над тем, как лучше представить данные - станции метрополитена (например, московского). В виде базы данных с таблицами и строками? В виде многомерного массива? В виде паскалевского типа record? Или еще как? Чтобы эти данные включали в себя всё: все станции, указание к какой линии они принадлежат, последовательность на линии, какие станции сколько линий связывают и т.д. Короче говоря, в каком виде план метрополитена лучше представить? Допустим, одна таблица - список линий метро. Вторая таблица - список станций и ссылка на линию (станция может принадлежать несколько линиям). Третья таблица - список пересечений линий. Непонятно, как указать направление линий и их взаимное расположение. Спасибо за помощь в виде мыслей и советов. 0

@Shamil1 Модератор 3137 / 2284 / 469 Регистрация: 26.03.2015 Сообщений: 8,888
	12.09.2016, 21:31
	Например, в реляционной базе данных. Хотя данных мало, и данные целиком считываются в память, так что можно хранить в любом формате (csv, xml, json,...) Линии: название, список ссылок на станции Станции: название, ссылка на линию, порядковый номер, список ссылок на переходы (пересадки), (если нужно) координаты (на карте и/или на схеме).. Станция не может принадлежать нескольким линиям! Станции на разных линиях могут иметь одинаковое название. Пересадки: ссылка на станцию1, ссылка на станцию2 0

@krapotkin 6851 / 4677 / 1465 Регистрация: 14.04.2014 Сообщений: 20,674 Записей в блоге: 21
	13.09.2016, 07:12
	да. это обычный граф. храним вершины - станции, и ребра - перегоны и переходы 0

@krapotkin 6851 / 4677 / 1465 Регистрация: 14.04.2014 Сообщений: 20,674 Записей в блоге: 21
	13.09.2016, 10:15
	таблица вершин таблица ребер Добавлено через 39 секунд ребра содержат ID первой и второй вершины 0