.archs | CMS Tables

Пока мне лень делать что-либо полезное, решился-таки накатать пару строк по построению фреймворков CMS. Начну, пожалую, с зарисовки простой, но, тем не менее, довольно гибкой структуры СУБД для поддержки структуры и контента сайта. Для начала хотелось бы определиться с возможным набором задач:

  • ЧПУ — всё и вся.
  • Глубокий (условно бесконечный) уровень вложенности данных (древовидная структура).
  • Многоязычность данных.
  • Хранение ревизий всех изменений данных.
  • Типизация данных – то бишь под адресом X, может быть галерея картинок с набором свойственной ей функционала, а под адресом Y будет простая страница, а под адресом Z будет гостевая книга.
  • Несколько адресов могут указывать на один контент

Как этого достичь? Довольно просто, на практике нужно всего две таблицы для разруливания «указателей» и N таблиц, на которые эти указатели будут ссылаться в поисках необходимых данных. Так, например, в таблице structure можно хранить само древо сайта, и будут у неё поля примерно такие, как я когда-то описывал в посте про посадку деревьев в PostgreSQL. На пару с таблицей structure нужно замутить мэппинг таблицу для корреляции URLов с определёнными данными. Структура может быть примерно такая

  • nodeidforeign key, references structure
  • objectid – указатель на ID объекста с контентом
  • objecttypeforeign key, указатель на тип объекта (дабы знать в какой таблице копаться)
  • languageforeign key, ID языка контента
  • version – serial, номер версии контента, при каждой редакции инкрементируется
  • modified – timestamp (триггером проставляется автоматом)
  • created – timestamp (триггером проставляется автоматом)

Вот и получилась у нас простая щастя, с помощью которой можно легко организовать сайт практически любой сложности и навороченности. Как быстро это будет летать? Всё зависит от кодера ;)

Top

Слова: coding, trees, databases

Комментарии Отключены

Латрек

А какой смысл в том чтобы гостевые книги были доступны только по адресу Z, а не скажем по адресу Z и Y/X/W ?

09.06.2005 // 18:22 [ ссылка ]

Ответ от Автора

дык я к этому и клоню ;))

любой материал может быть доступен по нескольким адресам, потому как в структуре участвуют только пойнтеры. Своего рода WinFS $)

09.06.2005 // 18:49 [ ссылка ]

Dargor

Спасибо. Очень познавательно.

09.06.2005 // 19:52 [ ссылка ]

Ответ от Автора

не вапрос, будет исчо!

10.06.2005 // 20:09 [ ссылка ]

otetz

У меня система базируется на подобных правилах, там правда пока-что есть то только ЧПУ, деревья да типы :) Остальное правда в не очень далёких планах...

Ну да суть не в этом. Я не стал выделать отдельной таблицы под URL-mapping, а просто ввёл понятие записи-редиректа - вполне удобно и достаточно.

10.06.2005 // 20:05 [ ссылка ]

Ответ от Автора

тогда появляется проблема, скажем у нас есть адрес

##http://foo.bar/something/##

и хочется мне, чтобы по этому адресу были доступны страницы на двух языках: русском и английском. Не держать же две записи в таблице с структурой ЧПУ, отнюдь, для этого и нужен маппер.

10.06.2005 // 20:08 [ ссылка ]

otetz

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

Единственный вариант это типа язык выбирается пользователем в настройках и потом он гуляет по сайту с этими настройками по урлам без языковых признаков - тут конечно да, маппинг стоит и отделить. Хотя не уверен, - над таким вариантом ещё особо не думал ;)

10.06.2005 // 20:22 [ ссылка ]

Ответ от Автора

пример — http://www.hotelbajazzo.com — мой сатй

11.06.2005 // 04:42 [ ссылка ]

Ktulhu

Черт! Что делать, и у меня подобная схема. Надеюсь это никто не запатентовал?

А насчет мультиязычности, [ ссылка ] поисковикам от такой организации мультиязычности как? В смысле, когда страница на разных языках доступна по одному и тому же урл. Помоему лучше все же язык в пути явно указывать... Хотя так конечно элегантнее

12.06.2005 // 23:08 [ ссылка ]

Ответ от Автора

язык в хедере отдаёшь + если есть желание, конечно, можно в <DOCTYPE> указать и в <head> — поисковики очень рады, когда есть такая инфа ;) правильно позиционируется контент.

12.06.2005 // 23:14 [ ссылка ]