Vizlim

Слышал о том, что современные форумы используют "Нитевую" структуру БД...

Интересно посмотреть на пример построение БД с использованием данной структуры...

И какие её достоинства и недостатки по сравнению с обычной древовидной структурой и со сбалансированном деревом (B-дерево)...

bazile

Нитевая структура? Что это такое?

Vizlim

Впервые о ней услышал тут: http://php.ru/forum/viewtopic.php?t=6199

bazile

Мне кажется что имеется в виду следующее: в виде дерева представляются только форумы, а сами сообщения хранятся как список.

Vizlim

Тоесть нечно на подобие:



tems:

id | Категория | tema | scil | kol-vo_tem | posl_mess | levelz |

1 | Общее | О форуме | podtema1 | 1 | Admin | true |

2 | Общее | О форуме2 | podtema2 | 1 | Admin | true |



podtema1:

ids | podtema | scil | num_mess | posled_mess | data | levelz |

1 | Новая тема | messagers1 | 1 | Admin | 2006-09-14 14:57:08 | false |

2 | Новая тема2 | messagers2 | 1 | Admin | 2006-09-14 15:30:05 | false |



messagers1:

ids | nick | messages |

1 | Admin | Сообщение |



messagers2:

ids | nick | messages |

1 | Admin | Сообщение |

bazile

Не смог твой пример понять. Ты бы хоть пояснил для чего каждая таблица нужна. Из "информативного" названия messagers2, например, это понять нельзя. Тоже самое касается названия поля scil.
Я имел в виду такую структуру БД, когда в таблице со списком форумов есть поле вроде Parent_ID указывающее на форум-родитель. Для тем же в качестве родителя выступает только ID форума. Например так:

Vizlim

-- Форумы

CREATE TABLE tems

(

id INT AUTO_INCREMENT PRIMARY KEY,

categori TINYTEXT, -- категория к который относятся темы

tema TINYTEXT, -- название темы

scil TINYTEXT, -- Ссылка на подтемы (название таблицы), данной темы

num_tem INT, -- кол-во тем

posl_mess TINYTEXT, --кто оставил последнее сообщение

levelz TINYTEXT -- Вложенность, уровень

)



-- Темы в форуме

CREATE TABLE "Ссылка на подтемы (название таблицы), данной темы"

(

ids INT AUTO_INCREMENT PRIMARY KEY,

podtema TINYTEXT, -- Название подтемы

scils TINYTEXT, -- Ссылка на сообщение (название таблицы), данной подтемы

num_mess INT, -- кол-во сообщений в теме

posled_mess TINYTEXT, -- кто оставил последнее сообщение в теме

datazz DATETIME, -- дата создания

levelz TINYTEXT -- Вложенность, уровень

)



-- Ответы на тему

CREATE TABLE "Ссылка на сообщение (название таблицы), данной подтемы"

(

ids INT AUTO_INCREMENT PRIMARY KEY,

nickname TINYTEXT, -- Логин

messaga LONGTEXT, -- Сообщение

datazz TINYTEXT -- дата

)



зы: как заполнчются поля в моём предыдущем посте =)



ззы: при каждой новой теме форума либо подтеме форума создаёться новая таблица...

Тоесть при наличии одной темы и 5 подтем имеем 6 таблиц...

при наличие 4 тем... и 0 подтем в каждой имеем 4 таблицы...





Мне интересно, если у нас есть только три таблицы и вних хранятся скажем "ccылки" на нужные данные, то если данных в таблице будет 1 миллион, то как скажется это на быстродействии, если при выборке нужных данных мы используем запрос SELECT (поиск)... при условии, что он проходится по всем записям в таблице...



И возникает ещё один вопрос, какая из структур будет эффективнее в работе... та которая имеет допустим 1 миллион таблиц либо структура с тремя таблицами с 1 миллионом полей и "ссылками" на данные в эти таблицы?

bazile

Подобная схема имеет ряд серьезных недостатков:<OL><LI>Для запросов придется использовать динамический SQL, что само по себе сразу ухудшает производительность.</LI><LI>Лишние накладные расходы на хранение большого кол-ва таблиц. Ведь кроме собственно данных есть еще и служебная информация о таблице. Плюс возможность (пусть даже и теоретическая) натолкнуться на физические ограничения СУБД на кол-во таблиц.</LI><LI>Создание тем и форумов будет требовать больше времени так как сначала требуется создать таблицу, после чего уже записывать данные.</LI><LI>Следствием п.3 является необходимость наличия у пользователя повышенных привилегий что противоречит общепринятой практике работы с минимально необходимыми привилегиями.</LI><LI>Сложнее будет сделать поиск, отбор всех сообщений пользователя и тому подобную функциональность.</LI><LI>Реляционные схемы построения базы обычно активно применяют механизмы защиты целостности базы предоставляемые самой СУБД. Например, внешние ключи. В данном же случае нельзя заранее создать отношения типа FOREIGN KEY. То есть надо или вообще отказываться от механимзмов зашиты - что глупо - или создавать подобные связи на лету вместе с таблицей - что влечет еще большие накладные расходы.</LI></OL>
Как итог: это плохая идея. Раз у нас реляционные СУБД, то и базы надо строить соответственно. Иначе жди проблем.
Насчет скорости работы тоже думаю все понятно.

Vizlim

Огромнейшее тебе СПАСИБО bazile, за помощь в структуре БД для форумов, а так же за разъяснения =))))))))))))))))))))))))))))))))))))))))

bazile

Пожалуйста.