|
|
|
Supreme Being
участник
Last Login: 29.05.2008 20:04
Сообщ.: 269,
Visits: 2 381
|
|
Слышал о том, что современные форумы используют "Нитевую" структуру БД...
Интересно посмотреть на пример построение БД с использованием данной структуры...
И какие её достоинства и недостатки по сравнению с обычной древовидной структурой и со сбалансированном деревом (B-дерево)...
----------------------------------
Я безработный...
Возьмите меня на работу. =)
|
|
|
|
|
Supreme Being
модератор
Last Login: 04.05.2008 13:32
Сообщ.: 7 240,
Visits: 65 445
|
|
| Нитевая структура? Что это такое?
|
|
|
|
|
Supreme Being
участник
Last Login: 29.05.2008 20:04
Сообщ.: 269,
Visits: 2 381
|
|
bazile (27.06.2007)
Нитевая структура? Что это такое?
Впервые о ней услышал тут: http://php.ru/forum/viewtopic.php?t=6199
----------------------------------
Я безработный...
Возьмите меня на работу. =)
|
|
|
|
|
Supreme Being
модератор
Last Login: 04.05.2008 13:32
Сообщ.: 7 240,
Visits: 65 445
|
|
| Мне кажется что имеется в виду следующее: в виде дерева представляются только форумы, а сами сообщения хранятся как список.
|
|
|
|
|
Supreme Being
участник
Last Login: 29.05.2008 20:04
Сообщ.: 269,
Visits: 2 381
|
|
bazile (28.06.2007)
Мне кажется что имеетсяв виду следующее: в виде дерева представляются только форумы, а сами сообщения хранятся как список.
Тоесть нечно на подобие:
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 | Сообщение |
----------------------------------
Я безработный...
Возьмите меня на работу. =)
|
|
|
|
|
Supreme Being
модератор
Last Login: 04.05.2008 13:32
Сообщ.: 7 240,
Visits: 65 445
|
|
| Не смог твой пример понять. Ты бы хоть пояснил для чего каждая таблица нужна. Из "информативного" названия messagers2, например, это понять нельзя. Тоже самое касается названия поля scil. Я имел в виду такую структуру БД, когда в таблице со списком форумов есть поле вроде Parent_ID указывающее на форум-родитель. Для тем же в качестве родителя выступает только ID форума. Например так: -- Форумы CREATE TABLE forum ( iForum_ID int NOT NULL PRIMARY KEY, iParentForum_ID int NULL, sForumName varchar NOT NULL, ) -- Темы в форуме
CREATE TABLE topic
(
iTopic_ID int NOT NULL PRIMARY KEY,
iForum_ID int NOT NULL,
iUser_ID int NOT NULL, -- Автор темы
sTopicName varchar NOT NULL, -- Название темы
sTopicBody varchar NOT NULL, -- Текст темы
dtCreated datetime NOT NULL, -- Дата создания темы
) -- Ответы на тему
CREATE TABLE topic_reply
(
iTopicReply_ID int NOT NULL PRIMARY KEY,
iTopic_ID int NOT NULL,
iUser_ID int NOT NULL, -- Автор ответа
sReplyBody varchar NOT NULL, -- Текст ответа
dtCreated datetime NOT NULL, -- Дата создания ответа
) |
|
|
|
|
Supreme Being
участник
Last Login: 29.05.2008 20:04
Сообщ.: 269,
Visits: 2 381
|
|
bazile (28.06.2007)
Не смог твой пример понять. Ты бы хоть пояснил для чего каждая таблица нужна. Из "информативного" названия messagers2, например, это понять нельзя. Тоже самое касается названия поляscil.
-- Форумы
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 таблицы...
Я имел в виду такую структуру БД, когда в таблице со списком форумов есть поле вроде Parent_ID указывающее на форум-родитель. Для тем же в качестве родителя выступает только ID форума.
Мне интересно, если у нас есть только три таблицы и вних хранятся скажем "ccылки" на нужные данные, то если данных в таблице будет 1 миллион, то как скажется это на быстродействии, если при выборке нужных данных мы используем запрос SELECT (поиск)... при условии, что он проходится по всем записям в таблице...
И возникает ещё один вопрос, какая из структур будет эффективнее в работе... та которая имеет допустим 1 миллион таблиц либо структура с тремя таблицами с 1 миллионом полей и "ссылками" на данные в эти таблицы?
----------------------------------
Я безработный...
Возьмите меня на работу. =)
|
|
|
|
|
Supreme Being
модератор
Last Login: 04.05.2008 13:32
Сообщ.: 7 240,
Visits: 65 445
|
|
Подобная схема имеет ряд серьезных недостатков:- Для запросов придется использовать динамический SQL, что само по себе сразу ухудшает производительность.
- Лишние накладные расходы на хранение большого кол-ва таблиц. Ведь кроме собственно данных есть еще и служебная информация о таблице. Плюс возможность (пусть даже и теоретическая) натолкнуться на физические ограничения СУБД на кол-во таблиц.
- Создание тем и форумов будет требовать больше времени так как сначала требуется создать таблицу, после чего уже записывать данные.
- Следствием п.3 является необходимость наличия у пользователя повышенных привилегий что противоречит общепринятой практике работы с минимально необходимыми привилегиями.
- Сложнее будет сделать поиск, отбор всех сообщений пользователя и тому подобную функциональность.
- Реляционные схемы построения базы обычно активно применяют механизмы защиты целостности базы предоставляемые самой СУБД. Например, внешние ключи. В данном же случае нельзя заранее создать отношения типа FOREIGN KEY. То есть надо или вообще отказываться от механимзмов зашиты - что глупо - или создавать подобные связи на лету вместе с таблицей - что влечет еще большие накладные расходы.
Как итог: это плохая идея. Раз у нас реляционные СУБД, то и базы надо строить соответственно. Иначе жди проблем. Насчет скорости работы тоже думаю все понятно.
|
|
|
|
|
Supreme Being
| | | |