हमेशा की तरह:कोई सबसे अच्छा समाधान नहीं है। प्रत्येक समाधान विभिन्न चीजों को आसान या कठिन बना देता है। आपके लिए सही समाधान इस बात पर निर्भर करता है कि आप सबसे अधिक कौन सा ऑपरेशन करेंगे।
अभिभावक-आईडी के साथ सरल दृष्टिकोण:
पेशेवरों:
-
लागू करने में आसान
-
एक बड़े सबट्री को दूसरे पैरेंट में ले जाना आसान है
-
इंसर्ट सस्ता है
-
आवश्यक फ़ील्ड सीधे SQL में पहुंच योग्य हैं
विपक्ष:
-
एक पूरे पेड़ को पुनः प्राप्त करना पुनरावर्ती है और इसलिए महंगा है
-
सभी माता-पिता को ढूंढना भी महंगा है (एसक्यूएल रिकर्सन नहीं जानता...)
संशोधित पूर्व-आदेश ट्री ट्रैवर्सल (एक प्रारंभ और समाप्ति बिंदु सहेजना):
पेशेवरों:
-
एक पूरा पेड़ प्राप्त करना आसान और सस्ता है
-
सभी माता-पिता को ढूंढना सस्ता है
-
आवश्यक फ़ील्ड सीधे SQL में पहुंच योग्य हैं
-
बोनस:आप चाइल्डनोड्स के क्रम को उसके पेरेंटनोड में भी सहेज रहे हैं
विपक्ष:
- सम्मिलित करना/अपडेट करना बहुत महंगा हो सकता है, क्योंकि आपको बहुत सारे नोड अपडेट करने पड़ सकते हैं
प्रत्येक नोड में पथ सहेजना:
पेशेवरों:
-
सभी माता-पिता को ढूंढना सस्ता है
-
एक पूरा पेड़ प्राप्त करना सस्ता है
-
सम्मिलित करना सस्ता है
विपक्ष:
-
पूरे पेड़ को हिलाना महंगा है
-
जिस तरह से आप पथ को सहेजते हैं, उसके आधार पर आप सीधे SQL में इसके साथ काम नहीं कर पाएंगे, इसलिए यदि आप इसे बदलना चाहते हैं, तो आपको हमेशा इसे लाने और पार्स करने की आवश्यकता होगी।
क्लोजर टेबल
पेशेवरों:
-
लागू करने में आसान
-
सभी माता-पिता को ढूंढना सस्ता है
-
सम्मिलित करना सस्ता है
-
पूरे पेड़ को पुनः प्राप्त करना सस्ता है
विपक्ष:
-
एक अतिरिक्त तालिका की आवश्यकता है
-
अन्य तरीकों की तुलना में बहुत अधिक स्थान लेता है
-
सबट्री को स्थानांतरित करना महंगा है
डेटा कितनी बार बदलता है, इसके आधार पर मैं अंतिम दो में से किसी एक को पसंद करूंगा।
यह भी देखें:http://media.pragprog.com/titles/bksqla/trees। पीडीएफ
