分层组的数据库模式

我正在为用作大型系统基础的组层次结构进行数据库设计.每个组都可以包含其他组,也可以包含"设备"作为叶子对象(设备下方没有任何内容).

正在使用的数据库是MS SQL 2005.(尽管在MS SQL 2000中工作将是一个奖励;但遗憾的是,此时需要MS SQL 2008的解决方案不可行).

有不同类型的组,这些组需要是动态的,并且在用户运行时是可定义的.例如,组类型可以是"客户","帐户","城市"或"建筑物","楼层",并且每种类型将具有可由用户定义的不同属性集.还将应用业务规则 - 例如,"楼层"只能包含在"建筑"组下面,并且这些可以在运行时定义.

许多应用程序功能来自基于这些组运行报告,因此需要一种相对快速的方法来获取某个组(以及所有子组)中包含的所有设备的列表.

使用修改的预订树遍历技术存储组具有快速的优势,但缺点是它相当复杂和脆弱 - 如果外部用户/应用程序修改数据库,则存在完全破坏的可能性.我们还实现了一个ORM层,这个方法似乎在大多数ORM库中使用关系变得复杂.

使用公用表表达式和"标准"id/parentid组关系似乎是避免运行多个递归查询的有效方法.这种方法有什么缺点吗？

至于属性,存储它们的最佳方法是什么？一个长而窄的桌子,与群体有关？是否应该将一个公共属性(如"name")存储在groups表中,而不是存储在属性表中(很多时候,名称将只显示所需的名称)？

是否会出现使用此方法的性能问题(假设在一个合理的硬件上,平均每个平均有6个属性,平均10个并发用户,例如,四核Xeon 2 Ghz,4GB ram ,折扣任何其他过程)？

随意提出一个与我在此概述的完全不同的架构.我只是想说明我关心的问题.