2

次の要件をデータベース テーブルに変換する方法には疑問があります。要件には、非常に動的な、より深いレベルのサブカテゴリがあります。次の例は、私の要件を説明します。

カテゴリ---->

         item1
         item2----->

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

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

                                  deeper sub item1

                   sub item5

         item3
         item4

将来的には、より深いサブ項目が存在する可能性があります。データベースが動的になるように分類する方法。

4

2 に答える 2

1

これは次の方法で実行できます。

ID 
Name 
ParentID

したがって、ゼロの ParentID が最上位になります。そこから永遠に続くことができます。

于 2012-11-21T05:19:17.297 に答える
1

あなたが探しているものと同様の作品フライアウトメニューの構造に、階層ストレージを使用しています。テーブル構造は次のとおりです。

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 主キー列への外部キーです。メニュー要素が他の既存のメニュー要素に関連付けられていることを強制し、最後に、ページの各言語バージョンのページデータを保持する他のテーブルにリンクされている URL 自体の言語と ID を強制します。

したがって、行は次のようになります。

ここに画像の説明を入力

それが保持する構造は次のとおりです。

<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 インクルード ファイルとして保存される) を時々再作成するような単純なことには、うまく機能します。

于 2012-11-21T05:50:59.787 に答える