तुम वहाँ एक मॉड्यूल PostgreSQL ltree कहा जाता है के लिए है पता हो सकता है ltree-। इसके अलावा, आप ltree की तुलना में, पूर्णांकों के लिए सरणी प्रकार का उपयोग करने (* 1, नीचे टिप्पणी देखें) संभावना है, जो इस परीक्षा में वास्तव में अपनी पुनरावर्ती प्रश्नों के साथ थोड़ी धीमी प्रदर्शन करने से पता चलता है - स्ट्रिंग अनुक्रमण (* 2 से छोड़कर, नीचे टिप्पणी देखें)।PostgreSQL बनाम पेड़ मॉड्यूल बनाम पूर्णांक/स्ट्रिंग सरणियों या स्ट्रिंग सीमांकित पथ
मैं हालांकि इन testresults की विश्वसनीयता के बारे में भी यकीन नहीं है।
मेरे सबसे बड़ा प्रश्न यहाँ अपेक्षाकृत अनजान है, और लगभग गैर-दस्तावेजी पेड़ मॉड्यूल के बारे में वास्तव में है। वर्णित here (जहां प्रलेखन भी पाया जा सकता है !!) के रूप में: hierachical डेटा प्रकार (lexicographical पेड़ों की तरह) के लिए
समर्थन, उचित documentation की कमी की वजह योगदान/पेड़ के पास जाना चाहिए, लंबित है। न केवल सामग्री, भी फ़ाइलें -
प्रलेखन के माध्यम से पढ़ने के बाद मैं थोड़ा या नहीं, मैं अपने बड़े आवेदन (एक सीएमएस, जहां सब कुछ एक hiearchical वृक्ष संरचना में संग्रहीत किया जाएगा आधार चाहिए के रूप में उलझन में हूँ इत्यादि, ताकि आप इसे जल्दी से देख सकें) लेट्री, सामान्य मटेरियलाइज्ड पाथ (पथ गणना) के साथ एक सीमांकित स्ट्रिंग या पथ के रूप में पूर्णांक सरणी के साथ - या यदि सिद्धांत में अपेक्षाकृत अज्ञात "पेड़" मॉड्यूल तेजी से प्रदर्शन करना चाहिए, अधिक स्केलेबल और दोनों का बेहतर समाधान।
मैं पहले से ही विश्लेषण किया है विभिन्न वृक्ष संरचना मॉडल और प्रदर्शन, scalability और नोड्स और subtrees अपने मुख्य आवश्यकताओं जा रहा है की पुनर्व्यवस्था क्वेरी करने के लिए कारण, मैं (पुनरावर्ती CTE के रूप में प्रदर्शन का समाधान नहीं होगा संलग्नता सूचियाँ से इनकार कर लिया है पेड़ के तराजू विशाल), नेस्टेड सेट/अंतराल (कुछ प्रश्नों में पर्याप्त तेज़ी से नहीं, पेड़ को जोड़ते समय इसके नुकसान पर विचार करते हुए), क्लोजर टेबल्स (जटिल पेड़ में बड़े पैमाने पर स्केलिंग में बहुत - मेरे जैसे इस तरह की एक बड़ी परियोजना के लिए उपयोगी नहीं) आदि और मटेरियलाइज्ड पाथ के साथ जाने का फैसला किया, जो पढ़ने के संचालन के लिए सुपर फास्ट है, और हाइर्चरी के आस-पास उपट्री और नोड्स को स्थानांतरित करना आसान बनाता है। तो प्रश्न केवल सामग्री के पथ के लिए प्रस्तावित कार्यान्वयन के सर्वोत्तम के बारे में है।
मैं "पेड़" PostgreSQL में के साथ अपने सिद्धांतों या अनुभव सुनने में विशेष रूप से उत्सुक हूँ।
मैं 2 से अधिक लिंक पोस्ट नहीं कर सका, इसलिए यहां उपर्युक्त संदर्भित यूआरएल हैं: 1) http://monkeyandcrow.com/blog/hierarchies_with_postgres/ और 2) http://gbif.blogspot.dk/2012/ 06/taxonomic-trees-in-postgresql.html अगर यह ब्याज का हो सकता है। – Dac0d3r
मुझे संदेह है कि 'contrib/tree' सिर्फ 'contrib/ltree' के शुरुआती संस्करणों का संदर्भ हो सकता है। मैंने कभी ऐसी किसी चीज़ के बारे में नहीं सुना है। –
लेट्री वास्तव में आसान और कुशल है। http://leopard.in.ua/2013/09/02/postgresql-ltree/ – Ajoy