क्या कोई हायरार्की का उपयोग वास्तविक उत्पादन में कुछ हजार पंक्तियों से अधिक उचित आकार की तालिकाओं के साथ कर रहा है? क्या यह विश्वसनीय / प्रदर्शनकारी है? अभी तक मैंने किसी को भी विक्रेता के साथ संबद्ध नहीं पाया है जो इसे सुझाता है, और पॉल नीलसन यहां इसके खिलाफ सलाह देते हैं ।
वास्तविक उत्पादन प्रणालियों में HierarchyId का उपयोग करने के साथ आपका अनुभव क्या है?
जब आप अपने विकल्पों पर HierarchyId का चयन कर रहे थे तो आपने कौन से मापदंड का उपयोग किया है?
जवाबों:
मैंने HierarchyID लागू किया है और इसे अच्छा प्रदर्शन और उपयोग करने में आसान प्रदान करने के लिए पाया है।
मैं इसे अपेक्षाकृत छोटे डेटासेट (हजारों पंक्तियों के दसियों) पर पदानुक्रम के साथ 10 शाखाओं तक गहरी उपयोग किया है।
इसका उपयोग क्यों करें? HierarchyID प्रकार कई सहायक विधियाँ प्रदान करता है (जैसे कि IsDescendantOf) जो आपके भौतिक पथ को रोल करने की तुलना में आपके काम को आसान बनाती हैं।
StackOverflow पर अधिक पॉल नीलसन टिप्पणी मेरे लिए भ्रामक - HierarchyID है एक materialized पथ। मैं उसके जवाब से नीचे इस टिप्पणी से सहमत होने के लिए अधिक इच्छुक हूं ।
एक बेहतर सवाल यह हो सकता है कि 'इसका इस्तेमाल क्यों न किया जाए'। इसका उपयोग करना आसान है, बहुत अधिक कार्यक्षमता प्रदान करता है जिसे आप अन्यथा अपने लिए लिख रहे होंगे, और अच्छा प्रदर्शन करेंगे (मेरे सीमित परीक्षणों में)।
यह किर्क के प्रश्न का उत्तर है कि 'इसका (HierarchyId) का उपयोग क्यों नहीं किया गया।' भौतिकवादी पथ की तुलना में, कुछ महत्वपूर्ण मामलों में HierarchyId दोनों कम प्रदर्शन करने वाले और काम करने में कम सुविधाजनक लगते हैं।
कारण सरल है: कनेक्ट पर Microsoft की टिप्पणी से उद्धृत , "समस्या यह है कि सीएलआर कॉल, जिसमें पदानुक्रम के तरीके शामिल हैं, क्वेरी ऑप्टिमाइज़र के लिए अपारदर्शी हैं। यह डिज़ाइन द्वारा है। हालांकि, इसका मतलब है कि उनके लिए कार्डिनैलिटी का अनुमान कभी-कभी काफी हो सकता है। गलत।"
दूसरी ओर, भौतिक पथ को लागू करना बहुत आसान है पहली बार हमें इसे करने की आवश्यकता है, और अगली बार यह अनिवार्य रूप से एक कॉपी-एंड-पेस्ट कार्य है। इसलिए, हम बहुत कम प्रयास के साथ अधिक बहुमुखी और बेहतर प्रदर्शन करने वाला समाधान प्राप्त करते हैं।
इसलिए मैं पॉल नीलसन से पूरी तरह सहमत हूं, जिन्होंने "Microsoft® SQL Server® 2008 बाइबिल" नामक अपनी उत्कृष्ट पुस्तक में लिखा है: "नया पदानुक्रम विवाद के बिना नहीं है। यह नया है और बहुत सारे प्रेस और डेमो समय मिलता है, लेकिन मैं। मुझे यकीन नहीं है कि यह एक समस्या है जिसे दूसरे समाधान की आवश्यकता है। "
मेरी कंपनी प्रत्यक्ष बिक्री, बहु-स्तरीय विपणन सॉफ्टवेयर में हीरिचिड का उपयोग करती है। यह काम करता हैं। मैंने वास्तव में इसके साथ कोई काम नहीं किया है मुझे पता है कि हम इसका उपयोग कर रहे हैं।
इसके साथ मैंने जो सबसे बड़ी समस्या देखी है, वह यह है कि हम अधिक सेट-बेस्ड होने के बजाय लूपिंग फैशन में स्तरों के माध्यम से पुनरावृत्ति कर रहे हैं। उस क्षेत्र में यह हमारे लिए वास्तविक प्रदर्शन नहीं करता है, लेकिन मुझे यकीन नहीं है कि अगर यह हमारे प्रकार या इसके कार्यान्वयन के साथ एक समस्या है।
पदानुक्रम के साथ एक समस्या यह है कि आपको वेंडर लॉक-इन मिलता है। लेकिन मुझे आदम मिलाज़ो द्वारा एक बढ़िया लेख मिला कि कैसे सब कुछ आंतरिक रूप से काम करता है:
http://www.adammil.net/blog/view.php?id=100
इसके साथ मैं MSSQL से अपने डेटा सेट को परिवर्तित करने के लिए एक पोस्टग्रेज स्क्रिप्ट लिखने में सक्षम था। इसे मैंने एक स्क्रिप्ट में शामिल किया, जिसे मैंने एडवेंचरवर्क्स डेटाबेस पोस्टग्रेज में आयात करने के लिए लिखा था:
https://github.com/lorint/AdventureWorks-for-Postgres
बस वहाँ स्थापित "ssll फ़ाइल में" पदानुक्रम "के लिए खोज और आप जल्द ही इसे परिवर्तित करने के लिए संदर्भ मिल जाएगा।
हमारी टीम ने इसे उत्पादन में लागू किया है, पहले प्रदर्शन में अच्छा है, 2 साल बाद, तालिका में अब 430,000 पंक्तियाँ हैं और गेटरोड और गेटडेंडेंट में 3 सेकंड लगते हैं, इन दोनों को रिकॉर्ड डालने के लिए अगले आईडी मान की गणना के लिए आवश्यक है। अब एक सिंगल सबट्री इंसर्शन में लगभग 16 सेकंड का समय लगता है जो बिल्कुल भी स्वीकार्य नहीं है।