Где хранить полный URL-адрес в cms?

Question

Я создаю cms и еще не определился с вопросом, где хранить полный URL данной страницы в структуре.

Каждая страница имеет пул (URL-имя страницы), и каждая страница имеет родительский и дочерний элементы, допускающие значение NULL (для страниц верхнего уровня).

Где мне хранить полный URL-адрес (/первая страница/подстраница) для данной страницы?Должно ли это храниться в базе данных вместе с другими свойствами страницы или в каком-то кеше?

Обновлять

Я спрашиваю не о дизайне базы данных, а о том, где хранить полный URL-адрес данной страницы, чтобы мне не нужно было проходить весь URL-адрес, чтобы получить страницу, запрошенную пользователем (/first-page/sub-page )

Обновление 2

Мне нужно определить, какая страница принадлежит запрошенному в данный момент URL-адресу.Если запрошенный URL-адрес /first-page/sub-page, я не хочу разбивать URL-адрес и проходить через базу данных (очевидно).

Я бы предпочел иметь весь URL-адрес в таблице, чтобы я мог просто выполнить один запрос (WHERE url = '/first-page/sub-page'), но это не кажется идеальным, что, если я изменю пул для родительская страница?Затем мне также нужно обновить поле URL для всех потомков.

Как другие люди решают эту проблему?Они помещают это в базу данных?В кеше, который сопоставляет /first-page-/sub-page с идентификатором страницы?Или они разделяют запрошенный URL-адрес и зацикливают базу данных?

Спасибо

Андерс

Answer 1

Сохраните его в кеше, поскольку веб-серверам придется постоянно искать URL-адреса.Если вы не ожидаете, что URL-адреса страниц будут меняться очень быстро, кэширование значительно снизит нагрузку на базу данных, которая обычно является вашим узким местом на веб-сайтах, управляемых базой данных.

По сути, вам нужен словарь, который сопоставляет URL-адрес -> все, что вам нужно для отображения страницы.Многие веб-серверы автоматически используют файловую систему операционной системы в качестве словаря и часто имеют встроенный кэш, который может распознавать изменения файлов в файловой системе.Вероятно, это будет намного эффективнее, чем все, что вы можете написать в своей CMS.Поэтому может быть лучше, если ваша CMS реализует структуру непосредственно в файловой системе и обрабатывает дополнительное сопоставление с помощью жестких или программных ссылок.

Answer 2

Я просто сделал это ради Мвкмс.Я придерживался идеи категорий/подкатегорий контента и страниц контента.Когда создается категория/подкатегория контента, я рекурсивно просматриваю родительские элементы и строю весь маршрут, а затем сохраняю его в таблице категорий.Затем, когда страница запрашивается, я могу найти правильную страницу контента и при просмотре структуры навигации узнать, является ли текущая создаваемая навигация текущим или активным маршрутом.

Этот подход требует некоторых правил относительно того, что происходит при редактировании категории.На данный момент подход заключается в том, что после того, как для подкатегории установлен полный путь, его нельзя изменить позже с помощью обычных инструментов.

Источник — mvccms.codeplex.com.