Страница 1 из 2
структура таблиц MS SQL для рубрикатора
Добавлено: 23 янв 2005, 17:57
Morfius
есть структура, аналогичная тематическому рубрикатору апорта, как её лучше реализовать с точки зрения быстродействия, выделяемого места, простоты последующей модификации кода и т.д.:
- поместить записи всех разделов и подразделов в одну таблицу,
- создать свою таблицу для каждого уровня подразделов
или
- создавать новую таблицу для каждого подраздела?
Добавлено: 24 янв 2005, 02:18
AiK
Зависит от того, какие выборки ты собираешься делать. Обычно подходит такой вариант: одна таблица под разделы, а вторая - для подразделов.
Добавлено: 24 янв 2005, 12:48
Morfius
Ясно.
А есть какие-то ограничения на количество записей и объём таблицы?
Добавлено: 24 янв 2005, 13:04
Absurd
Никаких практически достижимых. Только в отличие от Aik'а мне пришлось два раза напарываться - сначала просят раздел/подраздел, потом оказывается, что им нужна иерархическая структура с любой глубиной вложенности.
Так что теперь я сразу иерархическую структуру делаю. На Оракле такая фича встроена в PL/SQL, в MySQL придется наверное
это делать через вложенные множества.
Добавлено: 24 янв 2005, 13:49
Morfius
Absurd,
мне вобщем-то тоже структура с разной глубиной вложенности нужна,
то есть лучше действовать по пункту 2 (создать свою таблицу для каждого уровня подразделов )?
В mssql есть какие-нить дополнительные плюшки для создания иерархии?
Добавлено: 24 янв 2005, 14:31
AiK
Absurd, в моём сообщении нет ограничений на вложенность
Вообще можно сделать одну таблицу, но как правило это не очень удобно. Так что вторая таблица для подкатегорий может иметь такой вид
Код: Выделить всё
CREATE TABLE SUBCATEGORY (
subcategory_id int(10) NOT NULL auto_increment,
name varchar(50) NOT NULL,
category_id int(10) NOT NULL,
parent_id int(10) NULL,
PRIMARY KEY (subcategory_id),
FOREIGN KEY (category_id)
REFERENCES CATEGORY(category_id)
ON DELETE RESTRICT ON UPDATE RESTRICT
FOREIGN KEY (category_id)
REFERENCES SUBCATEGORY(subcategory_id)
ON DELETE RESTRICT ON UPDATE RESTRICT
) TYPE=INNODB;
А работа с этой таблицей - дело техники
Добавлено: 24 янв 2005, 15:32
Morfius
когда запрос будет работать быстрее: при выборке из одной таблицы с большим количеством записей, или при выборке из нескольких с малым количеством?
Добавлено: 24 янв 2005, 16:08
AiK
На сколько я помню, mySQL больше заточен на плоские выборки, т.е. из одной большой таблицы.
Добавлено: 24 янв 2005, 16:16
Morfius
AiK, а msSQL?
Добавлено: 24 янв 2005, 17:04
AiK
Morfius, вот блин. MS SQL через пробел пишется. И я и Absurd думали, что речь об MySQL идёт
В Books Online есть пример работы с древовидными структурами. Если речь идёт о произвольном уровне вложенности, то организовать её можно только при помощи одной таблицы (в некоторых случаях имеет смысл выделять главные разделы в отдельную таблицу). В противном случае, для прохода по всему дереву тебе придётся довольно извращённым способом определять список таблиц, участвующих в выборке и строить динамический запрос.
Что касается скорости выборки по одной длинной таблице и нескольким коротким. Если тебе для выборки придётся join'ить большую таблицу саму на себя, то маленькие таблицы предпочтительнее, хотя если есть индексы, то разница будет несущественная.
А вообще всё очень сильно зависит от запросов. Тебе для некоторых запросов может понадобится построить из маленьких таблиц болььшую, путём внешних объединений (outer join's) - такие запросы заведомо будут медленнее, чем по уже готовой таблице.