Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: хранение маршрутов в базе данных  (Прочитано 9448 раз)
0 Пользователей и 1 Гость смотрят эту тему.
eugrita
Помогающий

ru
Offline Offline

« : 20-04-2013 06:16 » 

 как хранить маршруты в базе данных. Маршрут -динамическая структура,
имеет переменное число промежуточных пунктов.
Предполагается в БД наличие 2 основных таблиц Nodes- табл.узлов и Links (табл ребер).
Граф - ориентированный
Можно конечно закодировать все пункты и представить маршрут как последовательность кодов пунктов
Вижу 2 альтернативы
1)Хранение маршрута каждый узел в своем поле БД
Недостатки - число полей БД фиксировано и можно лишь зарезервировать, например 30 или 50. Длину маршрута хранить в 1 поле. SQL запросы будут страшно длинными, неудобно, нужно каждый раз формировать в программном цикле.
Достоинства. Каждое поле-узел табл.reis можно связать каскадной связью с табл. узлов Node - т.е автоматич поддержка ссылочной целостности.

2)[Хранение маршрута в строковом (или веществ)поле.
резервируется мах число узлов например N=100 Каждый узел кодируется тогда 2 символами
Недостатки - сложность раскодирования. Писать программу разбивающая строку на пары соседн символов и преобразующие их в NN узлов. Никакой поддержки ссылочной целостности.
Если тип поля вещественный - доп.проблема БД обрезает ведущие нули скажем цепочка узлов 0 -2 -10
представленная как 000110 обрежется в БД до 110
Единственное достоинство - удобное хранение в длинном текстовом поле (длина 200 и выше)

Отдельной проблемой является хранение сопутствующих маршруту данных. Например расписания и стоимости проезда Их уже так не закодируешь как в 1 случае. Если скажем стоимость проезда между 2 пунктами аддитивно зависит от стоимости проезда по каждому ребру, то можно скажем хранить атрибуты стоимости и
время движения в табл ребер . Но в жизни это не всегда так. Кроме того можно учитывать особенности расписания - например некоторые пункты проезжают без остановки, тогда сумм время будет меньше суммы времен
« Последнее редактирование: 20-04-2013 06:25 от eugrita » Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 20-04-2013 06:39 » 

eugrita, как хочешь, так и храни. Ты не назвал ни одной проблемы или системного свойства (атрибута), на основании которых можно делать рациональный выбор. Поэтому и ответ: берёшь способ с потолка и хранишь.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #2 : 20-04-2013 07:01 » 

Я как вижу.
Первая таблица Route (Id:int, Name:string)
Вторая таблица Nodes (id:int, Name:string)
Третья таблица Paths (id:int, IdRoute:int, FromID:int, toID:int)

В третью таблицу просто загружаеш каждое ребро по отдельности. При выборке по idRoute получаеш полный маршрут.
Записан

Не будите спашяго дракона.
             Джаффар (Коша)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #3 : 20-04-2013 08:11 » new

eugrita, коли не знаешь, чего хочешь, не выдумывай сложностей и храни в виде списка. Так проще будет переделывать, когда ты наконец-то узнаешь, чего хочешь.

Finch, from-to достаточно при древовидном графе, но в реальности будет цикличность и нужно хранить список узлов. Причем в каждом направлении свой путь. Т.ч. я бы добавил четвертую (и пятую, которую ты пропустил — Edges) таблицу:

Edges (nodeFromID:int, nodeToId:int) -- PK(nodeFromID, nodeToId)
PathEdges (pathId:int, nodeFromID:int, nodeToId:int) -- PK(pathId, nodeFromID, nodeToId)

Edges — не избыточность, т.к. грани владеют различными атрибутами (например, длиной) вне зависимости от вхождения в маршруты.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines