Question

如何将以下要求转换为数据库表存在疑问。在动态需求中有更深层次的子分类。以下示例将解释我的要求：

类别----＆GT;

         item1
         item2----->

                   sub-item1
                   sub-item2------->

                                 deeper sub item1
                                 deeper sub item2
                   sub-item3
                   sub item4------->

                                  deeper sub item1

                   sub item5

         item3
         item4

将来可能会有更深入的子项目。如何分类以使数据库变得动态。

Answer 1

你可以这样做：

ID 
Name 
ParentID

因此，零的ParentID将是最高级别。从那里它可以永远持续下去。

Answer 2

我使用Hierarchical storage存储我的作品弹出菜单结构，类似于您要查找的内容。表结构如下：

CREATE TABLE IF NOT EXISTS `page_menu` (
  `menu_id` int(5) NOT NULL AUTO_INCREMENT,
  `menu_parent` int(5) DEFAULT NULL,
  `menu_sibling` int(5) DEFAULT NULL,
  `lang` char(2) NOT NULL,
  `url_id` int(10) NOT NULL,      
  PRIMARY KEY (`menu_id`),
  KEY `menu_parent` (`menu_parent`),
  KEY `menu_sibling` (`menu_sibling`),
  KEY `url_id` (`url_id`),
  KEY `lang` (`lang`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

ALTER TABLE `page_menu`
  ADD CONSTRAINT `page_menu_ibfk_1` FOREIGN KEY (`menu_parent`) REFERENCES `page_menu` (`menu_id`) ON DELETE SET NULL ON UPDATE CASCADE,
  ADD CONSTRAINT `page_menu_ibfk_2` FOREIGN KEY (`menu_sibling`) REFERENCES `page_menu` (`menu_id`) ON DELETE SET NULL ON UPDATE CASCADE,
  ADD CONSTRAINT `page_menu_ibfk_3` FOREIGN KEY (`url_id`) REFERENCES `page_desc` (`url_id`) ON DELETE CASCADE ON UPDATE CASCADE,
  ADD CONSTRAINT `page_menu_ibfk_4` FOREIGN KEY (`lang`) REFERENCES `lang` (`lang`) ON DELETE CASCADE ON UPDATE CASCADE;

所以基本上每个记录都有自己唯一的id（menu_id），并且还列出了一个可选的父项（根元素为NULL）和可选的较旧的兄弟（最老的同级也是NULL）这两个都是menu_id primary的外键用于强制与其他现有菜单元素关联的菜单元素的键列，最后是url本身的语言和id，它们链接到保存页面的每种语言版本的页面数据的其他表。

所以虽然行看起来像这样：

enter image description here

它拥有的结构是：

<ul>
    <li>1</li>
    <li>11
        <ul>
            <li>61
                <ul>
                    <li>111</li>
                    <li>121</li>
                </ul>
            </li>
            <li>71</li>
        </ul>
    </li>
    <li>21</li>
    <li>31</li>
    <li>41</li>
    <li>51</li>
</ul>

此方法的缺点是您无法单独使用SQL提取树，在您轻松重建树之前，需要进行一些处理才能按正确的顺序对记录进行排序。基本上你必须循环结果才能将它们重新排序为树的扁平版本，然后才能通过反向将子项附加到父项中来运行它。虽然不是很慢，但这不是很快，所以它可能不是一个合适的方法复杂的树，无法静态缓存在文件中。但是对于简单的事情，例如偶尔重新创建弹出菜单的嵌套结构（它被保存为html包含文件），它的效果很好。

像树一样的表的数据库建模，具有更深的子级别的子类别

2 个答案: