पदानुक्रम कार्यान्वयन - एक से कई के माध्यम से आसन्न सूची और भौतिक पथ का संयोजन

MySQL में पदानुक्रम को बनाए रखना एक बहुत ही घिसा-पिटा विषय है, बार-बार Habrt को स्मोक किया जाता है, हालांकि मुझे खुद के लिए इष्टतम संरचना नहीं मिली जो समर्थन और उपयोग में आसानी को जोड़ती है। साइकिल का आविष्कार खुद ...

निकटता सूची (AL) सुविधाजनक है:

• आत्मनिर्भर डेटा अखंडता (DELETE CASCADE पर)
• शाखाओं के सम्मिलन / स्थानांतरण में आसानी (अपडेट एक तत्व के एक पेरेंट_ड फील्ड को प्रभावित करता है)
• बच्चों को 1 स्तर के घोंसले के शिकार होने में आसानी

नमूना लेते समय मुख्य असुविधा उत्पन्न होती है:

• शाखा के सभी बच्चों को प्राप्त करना (घोंसले के स्तर पर प्रतिबंध के साथ एक मेनू के लिए)
• बच्चों की कुल संख्या प्राप्त करना (कैटलॉग जानकारी)
• आइटम (ब्रेडक्रंब, URL निर्माण) का पूरा रास्ता खोजें।

वे समाधान में कठिनाइयों का प्रतिनिधित्व नहीं करते हैं, लेकिन वे या तो स्तर की संख्या को हार्डकोड करते हैं या पुनरावृत्ति का सहारा लेते हैं। द्वारा और बड़े, आप इसके साथ रख सकते हैं, बदसूरत कोड के साथ कुछ फ़ंक्शन लिख सकते हैं और यह सब भूल सकते हैं। लेकिन!
भौतिकवादी पथ में पूर्ण पथ को संचय करने के विचार को देखने के बाद, मैं काफी समझ नहीं पाया, लेकिन क्या यह एक बाहरी तालिका में एक से कई संबंधों के साथ संग्रहीत होने से रोकता है? कोई कहेगा कि वे कहते हैं " यह पहले से ही था ", लेकिन एक महत्वपूर्ण अंतर है: parent_id !
So. पृष्ठ तालिका:

`id` int(10) unsigned NOT NULL AUTO_INCREMENT, `parent_id` int(10) unsigned DEFAULT NULL, `title` varchar(250) DEFAULT NULL, 

Pages_paths तालिका:

 `item_id` int(10) unsigned DEFAULT NULL, `parent_id` int(10) unsigned DEFAULT NULL, `level` tinyint(3) unsigned DEFAULT '0', `order` tinyint(3) unsigned DEFAULT '0', 

हम निर्भरता लिखते हैं:

 ALTER TABLE `pages` ADD CONSTRAINT `pages_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `pages` (`id`) ON DELETE CASCADE; ALTER TABLE `pages_paths` ADD CONSTRAINT `pages_paths_ibfk_2` FOREIGN KEY (`parent_id`) REFERENCES `pages` (`id`) ON DELETE CASCADE, ADD CONSTRAINT `pages_paths_ibfk_1` FOREIGN KEY (`item_id`) REFERENCES `pages` (`id`) ON DELETE CASCADE; 

इस प्रकार, आप एएल के साथ मौजूदा तालिका पर इस पद्धति को "लटका" सकते हैं और पहले से ही काम कर रहे तर्क के साथ हस्तक्षेप नहीं कर सकते हैं।
डालें और पेड़ के संचालन को संशोधित करने के लिए नियमित AL के साथ किया जाता है। किसी शाखा के मुख्य तत्व को हटाते समय, विदेशी कुंजी पथ के साथ तालिका में पूरी शाखा और निर्भरता को खींचती है।
नए तत्वों को जोड़ने और शाखाओं के बीच तत्वों को स्थानांतरित करने के चरण में एकमात्र हस्तक्षेप की आवश्यकता है। आप एक ट्रिगर लटका सकते हैं, लेकिन लोकप्रिय होस्टिंग के साथ अधिक संगतता के लिए, मैंने खुद को सरल PHP में सीमित करने और स्क्रिप्ट से अपडेट खींचने का फैसला किया।
मैंने 1000 मेजों और घोंसले के शिकार के 5 स्तरों के साथ एक मेज पर सब कुछ परीक्षण किया। अपने हाथों से पीड़ा न देने के लिए, उन्होंने एक साधारण टेबल हैमर लिखा:

 Tree::Fixture( 'pages', 1000, 5 ); 

आरंभ करने के लिए, आपको मौजूदा तालिका के लिए पथ आरंभ करने की आवश्यकता है:

 Tree::GeneratePaths('pages'); 

एक विकास मशीन पर इस तालिका को संसाधित करने में ~ 10 सेकंड का समय लगा। उसके बाद, पथ के पथ को सरल प्रश्नों के साथ पथ तालिका से बाहर निकाला जा सकता है:

 SELECT * FROM `pages_paths` pp JOIN `pages` p ON p.`id`=pp.`parent_id` WHERE item_id=:id ORDER BY `order` 

सभी बच्चों को इकट्ठा करें (या जोइन के बिना उनकी संख्या गिनें):

 SELECT * FROM `pages_paths` pp JOIN `pages` p ON p.`id`=pp.`item_id` WHERE pp.`parent_id`=:id ORDER BY pp.`level`, pp.`order` 

यदि हम एक तत्व जोड़ते हैं, तो हमें केवल रास्तों को अपडेट करने की आवश्यकता है, यदि हम चलते हैं, तो पहले हम पथों की पुरानी शाखा को धमाका करते हैं (item_id =: id OR parent_id =: id) और नए अद्यतनों में पथ:

 Tree::GeneratePaths( 'pages', $id ); 

100-200 तत्वों की एक शाखा के भीतर अपडेट 1 सेकंड के भीतर फिट होता है, जो मेरे कार्यों के लिए काफी स्वीकार्य है - केवल व्यवस्थापक ही देरी देखेंगे।
PHP क्लास और कोर एसक्यूएल का पूरा ध्यान रखें।
निष्कर्ष में, उपयोग के उदाहरण ( या पूरे ):

 //   $arr = Tree::GetPath( 'pages', $id ); //   $arr = Tree::GetChildren( 'pages', $id ); //  $num = Tree::GetChildrenCount( 'pages', $id ); 

मुझे खुशी होगी अगर कोई सुझाव दे सकता है कि सामान्य अनुक्रमण के निष्पादन समय को कैसे अनुकूलित किया जाए, एक MySQL प्रक्रिया के रूप में कार्यान्वयन, या अन्य चतुर विचार।