Xpoint
   [напомнить пароль]

Представление иерархической структуры сайта в реляционной БД

Метки: [без меток]
2006-01-10 21:57:52 [обр] wiktar(0/20)[досье]

Добрый день уважаемые господа!

Стараюсь найти наиболее правильное решение для хранения информации и структуры сайта.
Информацию первоначально предполагалось хранить в реляционной БД, и она же является единственным местом хранения информации. Теперь это не обязательное условие.

Идея в том, что сайт представляет собой иерархию страниц. Всё это должно управляться (создаваться, удаляться, перемещаться, копироваться) из панели администратирования (которую тоже буду писать я).

Если с хранением материала сайта всё понятно: строка в таблице - одна страница, которая обладает свойствами, такими как заголовок, автор, содержание и прочие, то с хранением структуры (иерархии) страниц дело обстоит сложнее. Как это лучше сделать с точки зрения реляционной БД?

  1. Хранить у каждого элемента список дочерних элементов.
  2. Хранить отдельно структуру сайта (на примере структуры ФС Unix):

0 :: /
1 :: etc
2 :: home
3 :: var
4 :: lib
5 :: victor
6 :: apt
7 :: apache2
8 :: tmp
9 :: log

А теперь иерархическая структура:

0 :: 1 , 2 , 3 , 8
1 :: 6 , 7
3 :: 9 , 4
2 :: 5

По этим данным я смогу восстановить всю иерархию каталогов.

Третьего варианта не знаю. Был совет о теории графов, но после консультации с другом, мы пришли к выводу, что для этих целей не подходит.

Очень явственно ощущаю, что я повторяю структуру файловой системы. И фактически, воспроизвожу иерархическую БД внутри реляционной.

Тогда, стоит ли иметь с этим дело?
Может быть лучше сразу использовать иерархическую? Например, XML + XPath?

Для хранения страниц сайта подходит идеально (если бы не недостатки в виде текстового хранения и прочее). Но какова поддержка со стороны PHP4? И как удобно в ней хранить неиерархические данные (типа плоского форума, каталога товаров?).

спустя 3 часа 42 минуты [обр] Ivan Kovalenko(0/5)[досье]

Есть мнение, что иерархия - всего лишь представление множества страниц. Или, проще говоря, некая упорядочивание кучи страниц. Другим примером упорядочивания является фасетная классификация. Это когда существует структура классов, по которым раскладывается множество страниц.

Если ближе к телу, то, наверное, правильно сделать фасетную классификацию страниц (она ближе к "кучной" природе множества страниц), после чего предоставить инструмент, который бы упорядочивал это дело в иерархию. Например, некоторые фасеты могут иметь иерархическую структуру. Или произвольное составление дерева из кучи страниц. В идеале это набор правил сопоставления части множества страниц месту в иерархии вместе с возможностью произвольного размещения страницы в данной иерархии.

спустя 19 минут [обр] wiktar(0/20)[досье]

Благодарю за интересный ответ. Впервые задумался над таким типом классификации. Если я правильно понял, прочитав Википедию (http://ru.wikipedia.org/wiki/%......%D0%BA%D0%B0%D1%86%D0%B8%D1%8F), то фасетная классификация в случае сайта сводится к ... к ... к чему?

Видимо к предоставлению странице параметров вида "категория: статьи, путешествия, чехия, прага". Ну или на английском "articles, travels, czech, praha".

Затем, при разборе URL: /articles/travels/czech/praha всё всё больше приближаемся к нужной странице?

Нет, я не до конца понимаю, если честно.

А файловая система (FAT32, NTFS...) - это суть древовидная СУБД?

спустя 1 час 5 минут [обр] Закиров Руслан(0/341)[досье]
Не знаю как применить фасетный вариант для структуры сайта, но для организации объектов подходит неплохо.
спустя 5 часов [обр] Cyrax(0/6)[досье]

в свою программисткую молодость приспичело мне реализовать свою коллекцию избранного (т.к. работа с Избранным в IE оставляла желать лучшего). в качестве хранилища данных была выбрана БД MS Access. структура ее свелась всего к двум таблицам: таблица категорий (или папок) и таблица непосредственно ссылок на сайты.

tblFolders (категории):

FolderID(ID категории, long, counter, key)
Name(название категории, text)
ParentID(ID родительской категории, long)

tblLinks (ссылки):

LinkID(ID ссылки, long, counter, key)
LinkURL(URL страницы)
LinkTitle(заголовок страницы)
Description(произвольное описание)
FolderID(ID категории к которой принадлежит ссылка, long)

естественно эту структуру можно изменить...

спустя 4 часа 3 минуты [обр] Сергей Ульянов[досье]
Можно здесь посмотреть по теме
спустя 2 часа 5 минут [обр] wiktar(0/20)[досье]

Поразмышляв, пришёл к выводу, что лучшим решением будет - просто указывать у каждой страницы её родителя.

Тогда перемещение сводится к простой смене родителя, удаление - вообще ничего не стоит, разве что пройтись рекурсивно по дочерним, если это нужно.

Всё отлично ложится на реляционную модель БД. Единственное, что - одна страница не может принадлежать более чем одному разделу. Не получится сделать что-то вроде hard link.

спустя 4 часа 31 минуту [обр] Алексей Севрюков(2/1280)[досье]

wiktar[досье]

Единственное, что - одна страница не может принадлежать более чем одному разделу. Не получится сделать что-то вроде hard link.

Категории отдельно, страницы отдельно. И таблицу связей сделать, тогда все получится.

спустя 5 часов [обр] wiktar(0/20)[досье]

Как будет выглядеть таблица связей?

По моим представлениям таблица со страницами будет выглядеть так,

idx :: Заголовок :: Текст :: родитель

Причем, родитель - это idx родительского пункта.

Буду рад услышать советы.

спустя 4 часа 52 минуты [обр] Закиров Руслан(0/341)[досье]
две таблицы:
idx :: Заголовок :: Текст
idx :: родитель
Powered by POEM™ Engine Copyright © 2002-2005