sql-server - 分层组的数据库架构

Question

我正在为用作更大系统基础的组层次结构设计数据库。每个组都可以包含其他组，也可以包含作为叶对象的“设备”(设备下面没有任何内容)。

正在使用的数据库是 MS SQL 2005。(虽然在 MS SQL 2000 中工作将是一个奖励；遗憾的是，目前需要 MS SQL 2008 的解决方案不可行)。

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

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

使用 modified pre-order tree traversal 存储组该技术的优点是速度快，但缺点是它相当复杂和脆弱 - 如果外部用户/应用程序修改数据库，则有可能完全损坏。我们还实现了一个 ORM 层，这种方法似乎使大多数 ORM 库中的关系使用变得复杂。

使用 common table expressions “标准”id/parentid 组关系似乎是避免运行多个递归查询的有效方法。这种方法有什么缺点吗？

至于属性，最好的存储方式是什么？与团队相关的又长又窄的 table ？是否应该将一个公共(public)属性(如“名称”)存储在组表中，而不是属性表中(很多时候，名称将是显示所需的全部内容)？

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

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

Answer 1

我建议您实际构建最容易维护的方式(“标准”父/子设置)并至少运行一些基本基准测试。

您会惊讶于数据库引擎可以通过适当的索引来做什么，尤其是当您的数据集可以放入内存时。

假设每组 6 个属性、2000 个组和 30 个字节/属性，您说的是 360KB* 预期项目/组 -- 图 400KB。如果您希望有 1000 个项目/组，那么您只需要查看 400MB 的数据——这将毫无问题地放入内存中，并且当所有数据都在数据库中时，数据库在连接时快速内存。