Я работаю над дизайном базы данных для иерархии групп, используемой в качестве основы более крупной системы. Каждая группа может содержать другие группы, а также «устройства». как объекты листа (ничто не идет ниже устройства).

Используемая база данных - MS SQL 2005. (Хотя работа в MS SQL 2000 была бы плюсом; решение, требующее MS SQL 2008, к сожалению, пока невозможно).

Существуют различные типы групп, и они должны быть динамическими и определяемыми пользователями во время выполнения. Например, типами групп могут быть «клиент», «учетная запись», «город» или «здание», «этаж», и каждый тип будет иметь свой набор атрибутов, определяемый пользователем. , Будут также применяться бизнес-правила - например, «пол» может содержаться только под «зданием» группа, и опять же, это определяется во время выполнения.

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

Хранение групп с использованиеммодифицированный обход дерева предзаказа Техника имеет преимущество в том, что она быстрая, но недостаток в том, что она довольно сложная и хрупкая - если внешние пользователи / приложения изменяют базу данных, существует вероятность полного ее поломки. Мы также реализуем слой ORM, и этот метод, кажется, усложняет использование отношений в большинстве библиотек ORM.

С помощьюобщие табличные выражения и «стандартный»; Отношение id / parentid к группам кажется мощным способом избежать запуска нескольких рекурсивных запросов. Есть ли недостатки этого метода?

Что касается атрибутов, каков наилучший способ их хранения? Длинный, узкий стол, относящийся к группе? Если есть общий атрибут, такой как & quot; имя & quot; храниться в таблице групп, а не в таблице атрибутов (большую часть времени имя будет всем, что требуется для отображения)?

Будут ли проблемы с производительностью при использовании этого метода (допустим, что в среднем достаточно 2000 групп со средним числом 6 атрибутов в каждой и в среднем 10 одновременно работающих пользователей) на приемлемом оборудовании, например четырехъядерном Xeon 2 ГГц, 4ГБ оперативной памяти, дисконтирование каких-либо других процессов)?

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