Мдя... вы даете, ребята. (ну или я чего то не понял)

Хранить легко:
один-ко-многим. Мастер - маршрут (id, всякая ерунда). подчиненка - id точек и какое-нить поле типа очередность (чтобы по нему order by делать)

eugeneEugene
1)по спец-запросу отобразить перечень пунктов маршрута включая нач, конечный, и промежуточн
(при этом маршруты могут быть самопересекающимися и кольцевыми.
и 2 вида информации

select по подчиненке where id_marchrut = нужный_нам

eugene
1.1 характеристики транзитных пунктов

К тому же запросу лепишь join на справочник точек маршрутов

eugene
1.2 характеристики рёбер (например время поездки и расстояние от промежут пункта до следующего пункта маршрута.

ну тут все зависит от того КАК будут хранится ребра. (напрмиер координаты вершин или длина всех ребер). Но имхо - это лучше в клиента вынести (просто по каждому результату у тебя будет доп запрос)

eugene
1.3 Если есть несколько маршрутов ведущих из п.А в п.B надо сконструировать запрос ихи хранимую процедуру, выводящую все эти маршруты с информацией о времени поездки и какой-то другой.
\ВОТ и ВСЁ!!!
Ухты это и называется ХРАНЕНИЕ В БД? А по моему на SQL Вы пытаетесь навесить проблемы программирования, для которых необходимо использовать нормальные ЯВУ.
(кстати, если уж совсем нужно получать эту информацию "из БД" то большинство из них поддерживают функции пользователя - можно попробовать и на них сделать такое - но это не более чем подгонка результата)
А та задача, про которую идет разговор в 1.3 это классика из теории графов.