структура таблиц MS SQL для рубрикатора

[Morfius]

есть структура, аналогичная тематическому рубрикатору апорта, как её лучше реализовать с точки зрения быстродействия, выделяемого места, простоты последующей модификации кода и т.д.:
- поместить записи всех разделов и подразделов в одну таблицу,
- создать свою таблицу для каждого уровня подразделов
или
- создавать новую таблицу для каждого подраздела?

[AiK]

Зависит от того, какие выборки ты собираешься делать. Обычно подходит такой вариант: одна таблица под разделы, а вторая - для подразделов.

[Morfius]

Ясно.
А есть какие-то ограничения на количество записей и объём таблицы?

[Absurd]

Никаких практически достижимых. Только в отличие от Aik'а мне пришлось два раза напарываться - сначала просят раздел/подраздел, потом оказывается, что им нужна иерархическая структура с любой глубиной вложенности.
Так что теперь я сразу иерархическую структуру делаю. На Оракле такая фича встроена в PL/SQL, в MySQL придется наверное
это делать через вложенные множества.

[Morfius]

Absurd,
мне вобщем-то тоже структура с разной глубиной вложенности нужна,
то есть лучше действовать по пункту 2 (создать свою таблицу для каждого уровня подразделов )?

В mssql есть какие-нить дополнительные плюшки для создания иерархии?

[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;

А работа с этой таблицей - дело техники

[Morfius]

когда запрос будет работать быстрее: при выборке из одной таблицы с большим количеством записей, или при выборке из нескольких с малым количеством?

[AiK]

На сколько я помню, mySQL больше заточен на плоские выборки, т.е. из одной большой таблицы.

[Morfius]

AiK, а msSQL?

[AiK]

Morfius, вот блин. MS SQL через пробел пишется. И я и Absurd думали, что речь об MySQL идёт
В Books Online есть пример работы с древовидными структурами. Если речь идёт о произвольном уровне вложенности, то организовать её можно только при помощи одной таблицы (в некоторых случаях имеет смысл выделять главные разделы в отдельную таблицу). В противном случае, для прохода по всему дереву тебе придётся довольно извращённым способом определять список таблиц, участвующих в выборке и строить динамический запрос.

Что касается скорости выборки по одной длинной таблице и нескольким коротким. Если тебе для выборки придётся join'ить большую таблицу саму на себя, то маленькие таблицы предпочтительнее, хотя если есть индексы, то разница будет несущественная.
А вообще всё очень сильно зависит от запросов. Тебе для некоторых запросов может понадобится построить из маленьких таблиц болььшую, путём внешних объединений (outer join's) - такие запросы заведомо будут медленнее, чем по уже готовой таблице.