diamond_krnl
pure-php
Древо сайта в БД
Есть таблица следующей структуры:
[sql]
CREATE TABLE `htdocs`
(
`id` mediumint(8) unsigned NOT NULL auto_increment,
`id_parent` mediumint(8) unsigned default '0',
`id_maket` mediumint(8) unsigned NOT NULL default '0',
`name` varchar(255) NOT NULL default '',
`path` varchar(255) default NULL,
`level` tinyint(4) unsigned default NULL,
`pos` tinyint(4) unsigned NOT NULL default '0',
`hidden` tinyint(4) unsigned default '0',
`perm` tinyint(4) unsigned default '0',
`sort` varchar(128) NOT NULL default '',
`title` varchar(255) NOT NULL default '',
`content` text,
`meta_author` varchar(255) default NULL,
`meta_keywords` varchar(255) default NULL,
`meta_description` varchar(255) default NULL,
`created` int(10) unsigned NOT NULL default '0',
`updated` int(10) unsigned NOT NULL default '0',
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`id_parent`,`name`),
UNIQUE KEY `path` (`path`)
);
[/sql]
Цель её - хранение статистики сайта в БД, посредством вызова через 404 или mod_rewrite.
В таблице заложенна избыточность в жертву производительности, что собственно меня волнует.
Описание полей:
id - код записи
id_parent - код предка
id_maket - код дизайн-макета
name - имя, ключевое слово в разделе родителя.
path - полный путь до документа, т.е. путь родиля + своё имя.
level - уровень в дереве.
pos - позиция в раделе.
hidden - скрытен/виден, наследуется.
perm - открытый/закрытый публичный доступ в раздел, наследуется.
sort - глобальное поле сортировки,т.е. поле sort родиля + своё поле pos (запись с заполнением нулями слева)
title - заголовок страницы.
content - html.
meta_author - мета-тег.
meta_keywords - мета-тег.
meta_description - мета-тег.
created - дата создания.
updated - дата редактирования.
Принцип действия:
при переносе,вставки,удаление,редактирование узла происходит - блокирование таблицы, полная выборка на всю таблицу, пересчёт зависимых от предков полей: path,level,hidden,perm,sort...
Операцию ресурсоёмка(для большого количества узлов), но админ сайт не так уж часто редактирует структуру сайта, не беда вообщем.
Есть соблазн разделить на две таблицы, и все поля зависмые от предков, вынесте туда.
или...?
Прошу конструктивной критики. (=
Спасибо.
Есть таблица следующей структуры:
[sql]
CREATE TABLE `htdocs`
(
`id` mediumint(8) unsigned NOT NULL auto_increment,
`id_parent` mediumint(8) unsigned default '0',
`id_maket` mediumint(8) unsigned NOT NULL default '0',
`name` varchar(255) NOT NULL default '',
`path` varchar(255) default NULL,
`level` tinyint(4) unsigned default NULL,
`pos` tinyint(4) unsigned NOT NULL default '0',
`hidden` tinyint(4) unsigned default '0',
`perm` tinyint(4) unsigned default '0',
`sort` varchar(128) NOT NULL default '',
`title` varchar(255) NOT NULL default '',
`content` text,
`meta_author` varchar(255) default NULL,
`meta_keywords` varchar(255) default NULL,
`meta_description` varchar(255) default NULL,
`created` int(10) unsigned NOT NULL default '0',
`updated` int(10) unsigned NOT NULL default '0',
PRIMARY KEY (`id`),
UNIQUE KEY `name` (`id_parent`,`name`),
UNIQUE KEY `path` (`path`)
);
[/sql]
Цель её - хранение статистики сайта в БД, посредством вызова через 404 или mod_rewrite.
В таблице заложенна избыточность в жертву производительности, что собственно меня волнует.
Описание полей:
id - код записи
id_parent - код предка
id_maket - код дизайн-макета
name - имя, ключевое слово в разделе родителя.
path - полный путь до документа, т.е. путь родиля + своё имя.
level - уровень в дереве.
pos - позиция в раделе.
hidden - скрытен/виден, наследуется.
perm - открытый/закрытый публичный доступ в раздел, наследуется.
sort - глобальное поле сортировки,т.е. поле sort родиля + своё поле pos (запись с заполнением нулями слева)
title - заголовок страницы.
content - html.
meta_author - мета-тег.
meta_keywords - мета-тег.
meta_description - мета-тег.
created - дата создания.
updated - дата редактирования.
Принцип действия:
при переносе,вставки,удаление,редактирование узла происходит - блокирование таблицы, полная выборка на всю таблицу, пересчёт зависимых от предков полей: path,level,hidden,perm,sort...
Операцию ресурсоёмка(для большого количества узлов), но админ сайт не так уж часто редактирует структуру сайта, не беда вообщем.
Есть соблазн разделить на две таблицы, и все поля зависмые от предков, вынесте туда.
или...?
Прошу конструктивной критики. (=
Спасибо.