0

我正在考虑将我的组织层次结构转换为从这里收集的嵌套集合模型。我把它放在一个SqlFiddle中，希望能帮助可视化它。有什么是简化的，有/将会有更多的级别，但这应该适合帮助解释。

在我的组织中，教练经常更换。平均每年每支球队会有2-3名新教练，教练会在组织中上下变动，波动很大。在教练之上，一切都将保持不变，但可能/将会发生变化。

使用我们的旧模型（邻接列表），我们能够通过由触发器填充的其他表来跟踪更改，但是这个新模型将有新的跟踪要求。我看到我们需要跟踪rgt和lft数字，以及删除日期和添加日期。此外，我看到为任何给定日期或日期范围“重建”树的一些复杂性。

我考虑过的两个选项是：

首先，创建一个表来跟踪更改，跟踪rgt和lft列以及日期值，然后从树中删除教练/团队。我认为这种方式很难“重建”历史查找。

其次，将“移除”的教练/团队留在树中，向树中添加一个布尔值，指示教练/组织是否仍在使用中，并添加一个仅跟踪日期和前父级的更改表。这将使历史查找更容易（我认为日期范围方面很困难），但会使树变得混乱和膨胀。

哪个选项会更好？有没有我错过的选项？

我们会经常使用历史查询，但对于一次性查询，所有聚合数据将在第二天按组织级别进行编译和存储。

4

1 回答 1

0

实际上并不清楚您具体进行了哪些跟踪和历史查找。但是，对于您的问题，我有一个一般性的答案。

嵌套集和邻接表模型并不相互排斥。这意味着您可以在一个表中同时使用这两者，就像下面的架构一样。

CREATE TABLE `node` (
  `node_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `parent_id` int(10) unsigned DEFAULT NULL,
  `l` int(10) unsigned NOT NULL,
  `r` int(10) unsigned NOT NULL,
  `name` varchar(32) NOT NULL,
  PRIMARY KEY (`node_id`),
  KEY `l` (`l`),
  KEY `r` (`r`),
  KEY `parent_id` (`parent_id`),
  CONSTRAINT `node_has_node` FOREIGN KEY (`parent_id`)
    REFERENCES `node` (`node_id`)
    ON DELETE CASCADE
    ON UPDATE CASCADE
) ENGINE=InnoDB;

使用此模式，很容易查询子树的节点并用 和 计算l它们r。同时，使用 和 编写处理直接上升和下降节点的查询也很node_id容易parent_id。

因此，我建议您使用嵌套集标记扩展您的表格，而不会消除父引用。因此，您可以继续使用现有的跟踪逻辑，并具有嵌套集合模型的优势。

于 2014-11-27T12:13:23.437 回答