我有一个产品目录。每个类别由不同数量(深度)的子类别组成。级别(深)的数量是未知的,但我很确定它不会超过 5,6 级别。数据更改比读取要少得多。
问题是:哪种类型的分层数据模型更适合这种情况。该项目基于 Django 框架,应考虑其特性(管理 i-face、模型处理......)。
非常感谢!
我有一个产品目录。每个类别由不同数量(深度)的子类别组成。级别(深)的数量是未知的,但我很确定它不会超过 5,6 级别。数据更改比读取要少得多。
问题是:哪种类型的分层数据模型更适合这种情况。该项目基于 Django 框架,应考虑其特性(管理 i-face、模型处理......)。
非常感谢!
Nested sets
如果您不需要频繁更新或分层排序,则性能更好。
如果您需要树更新或分层排序,最好使用parent-child
数据模型。
它很容易在Oracle
and中构建SQL Server 2005+
,而不是那么容易(但仍然可能)在MySQL
.
对于这种分层数据,我会使用改进的预序树遍历算法 MPTT。如果您不介意对结构的更改有一点惩罚,这可以在遍历树和查找子节点时提供出色的性能。
幸运的是,Django 有一个很棒的库django-mptt。我已经在许多项目中使用了它,并取得了很大的成功。还有django-treebeard提供了几种替代算法,但我没有使用它(而且它似乎不像 mptt 那样受欢迎)。
根据这些文章:
http://explainextended.com/2009/09/24/adjacency-list-vs-nested-sets-postgresql/ http://explainextended.com/2009/09/29/adjacency-list-vs-nested-sets- mysql/
“MySQL 是四大(MySQL、Oracle、SQL Server、PostgreSQL)中唯一一个嵌套集模型表现出不错性能并且可以考虑存储分层数据的系统。”
邻接表更容易维护,嵌套集的查询速度更快。
问题一直在于将邻接列表转换为嵌套集花费了太长时间,这要归功于加载了 RBAR 的非常讨厌的“推送堆栈”方法。所以人们最终会在嵌套集合中进行一些非常困难的维护或不使用它们。
现在,你也可以吃蛋糕了!您可以在不到 4 秒的时间内对 100,000 个节点进行转换,并在不到一分钟的时间内对一百万行进行转换!顺便说一句,全部在 T-SQL 中!请参阅以下文章。