डेटाबेस संरचना सलाह की आवश्यकता

सबसे पहले, यूजर इंटरफेस: उपयोगकर्ता के रूप में मैं नफरत करता हूं कड़ाई से पदानुक्रमित . में व्यवस्थित कैटलॉग में किसी उत्पाद को खोजने के लिए मार्ग। मुझे कभी याद नहीं है कि एक "विदेशी" उत्पाद किस उप-उप-उप-उप-श्रेणी में है और यह मुझे "आशाजनक" श्रेणियों की खोज में समय बर्बाद करने के लिए मजबूर करता है ताकि यह पता चल सके कि इसे वर्गीकृत किया गया है (मेरे लिए, कम से कम ) अजीब तरीका।

क्या केविन पेनो सुझाव एक अच्छी सलाह है और इसे पहचान ब्राउज़िंग के रूप में जाना जाता है . मर्सिया बेट्स के रूप में में लिखा डॉट-बम के बाद :इस बार वेब सूचना पुनर्प्राप्ति का अधिकार प्राप्त करना , " .. पहलू वर्गीकरण श्रेणीबद्ध वर्गीकरण के लिए है क्योंकि संबंधपरक डेटाबेस पदानुक्रमित डेटाबेस के लिए हैं। .. ".

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

पहलू खोज क्या है, इसे तुरंत समझने के लिए, कुछ डेमो हैं पर एक्सप्लोर करने के लिए ।

दूसरा, अनुप्रयोग तर्क: क्या Manitra प्रस्ताव भी एक अच्छी सलाह है (जैसा कि मैं इसे समझता हूं), यानी nodes . को अलग करना और links विभिन्न संबंधों में एक पेड़/ग्राफ का। जिसे वे "पूर्वजों की तालिका" कहते हैं (जो कि एक बेहतर सहज ज्ञान युक्त नाम है) के रूप में जाना जाता है। एक निर्देशित चक्रीय ग्राफ (DAG) का संक्रमणीय समापन (पहुंचने योग्य संबंध)। जैसा कि मनित्रा ने कहा, प्रदर्शन से परे, यह प्रश्नों को बहुत सरल करता है।

लेकिन मेरा सुझाव है कि एक देखें ऐसी "पूर्वज तालिका" (सकर्मक बंद) के लिए, ताकि अद्यतन वास्तविक समय और वृद्धिशील हों, बैच नौकरी द्वारा आवधिक नहीं। मेरे द्वारा ग्राफ़ सेट के लिए क्वेरी भाषा:डेटा मॉडलिंग प्रश्न . विशेष रूप से, ग्राफ के ट्रांजिटिव क्लोजर को बनाए रखना देखें। एसक्यूएल में (.ps - पोस्टस्क्रिप्ट)।

उत्पाद-श्रेणियां संबंध

मनित्रा का पहला बिंदु भी जोर देने योग्य है।

वह जो कह रहा है वह यह है कि उत्पादों और श्रेणियों के बीच कई-से-अनेक संबंध हैं। यानी:प्रत्येक उत्पाद एक या अधिक श्रेणियों में हो सकता है और प्रत्येक श्रेणी में शून्य या अधिक उत्पाद हो सकते हैं।

दिए गए संबंध चर (रिलेवर) उत्पाद और श्रेणियां ऐसे संबंधों का प्रतिनिधित्व किया जा सकता है, उदाहरण के लिए, संबंधित उत्पादों और श्रेणियों के साथ विदेशी-कुंजी संबंधों में कम से कम विशेषताओं पी # और सी #, यानी उत्पाद और श्रेणी संख्या (पहचानकर्ता) के साथ एक रिलेवर पीसी के रूप में। नंबर।

यह श्रेणियों के पदानुक्रम के प्रबंधन का पूरक है। बेशक, यह केवल एक डिज़ाइन स्केच है।

एसक्यूएल में पहलू ब्राउज़िंग पर

"फ़ैसिटेड ब्राउजिंग" को लागू करने के लिए एक उपयोगी अवधारणा है रिलेशनल डिवीजन , या, यहां तक कि, संबंधपरक तुलना (लिंक किए गए पृष्ठ के नीचे देखें)। अर्थात। पीसी (उत्पाद-श्रेणियों) को एक उपयोगकर्ता (पहलू नेविगेशन) से चुनी गई श्रेणियों की (बढ़ती) सूची से विभाजित करने पर ऐसी श्रेणियों में केवल उत्पाद प्राप्त होते हैं (बेशक, श्रेणियों को नहीं माना जाता है। सभी परस्पर अनन्य, अन्यथा दो श्रेणियों को चुनने पर शून्य उत्पाद प्राप्त होंगे)।

एसक्यूएल-आधारित डीबीएमएस में आमतौर पर इस ऑपरेटर (विभाजन और तुलना) की कमी होती है, इसलिए मैं नीचे कुछ दिलचस्प कागजात देता हूं जो उन्हें लागू/चर्चा करते हैं:

रिलेशनल डिवीजन को व्यापक बनाने पर (.pdf FIE 2003 सेशन इंडेक्स से );
रिलेशनल डिवीजन के लिए एक सरल (और बेहतर) SQL दृष्टिकोण (.pdf जर्नल ऑफ इन्फॉर्मेशन सिस्टम्स एजुकेशन से - Contents Volume 13, Number 2 (2002) );
डिवीजन और सेट कंटेनमेंट जॉइन ऑपरेटर्स द्वारा बार-बार आइटमसेट की खोज क्वेरी को प्रोसेस करना ;
डिवीजन ऑपरेटरों वाले प्रश्नों को फिर से लिखने के लिए कानून ;
रिलेशनल डेटाबेस में यूनिवर्सल क्वांटिफिकेशन के लिए एल्गोरिदम और एप्लिकेशन;

ऑब्जेक्ट-ओरिएंटेड में यूनिवर्सल क्वांटिफिकेशन के साथ क्वेरी को ऑप्टिमाइज़ करना और ऑब्जेक्ट-रिलेशनल डेटाबेस ;
(ACM एक्सेस की आवश्यकता है) डिवीजन और सेट की जटिलता पर रिलेशनल में जुड़ता है बीजगणित ;
(ACM एक्सेस की आवश्यकता है) बड़े डेटाबेस में यूनिवर्सल क्वांटिफिकेशन के लिए तेज़ एल्गोरिदम;

और इसी तरह...

मैं यहां विवरण में नहीं जाऊंगा लेकिन श्रेणियों के पदानुक्रम और पहलू ब्राउज़िंग के बीच बातचीत को विशेष देखभाल की आवश्यकता है।

"सपाटपन" पर विषयांतर

मैंने संक्षेप में Pras द्वारा लिंक किए गए लेख को देखा। , MySQL में पदानुक्रमित डेटा प्रबंधित करना , लेकिन मैंने परिचय में इन कुछ पंक्तियों के बाद पढ़ना बंद कर दिया:

यह समझने के लिए कि रिश्तों की समतलता पर यह जिद क्यों है सिर्फ बकवास , एक तीन आयामी कार्टेशियन निर्देशांक प्रणाली में एक घन की कल्पना करें :इसकी पहचान 8 निर्देशांकों (ट्रिपलेट्स) द्वारा की जाएगी, मान लीजिए P1(x1,y1,z1), P2(x2,y2,z2), ..., P8(x8, y8, z8) [यहां हम इससे संबंधित नहीं हैं इन निर्देशांकों पर प्रतिबंध ताकि वे वास्तव में एक घन का प्रतिनिधित्व करें]।

अब, हम इन निर्देशांकों (बिंदुओं) को एक संबंध चर में रखेंगे और हम इस चर को Points नाम देंगे। . हम प्रतिनिधित्व करेंगे Points . का संबंध मान नीचे दी गई तालिका के रूप में:

Points|  x |  y |  z |
=======+====+====+====+
       | x1 | y1 | z1 |
       +----+----+----+
       | x2 | y2 | z2 |
       +----+----+----+
       | .. | .. | .. |
       | .. | .. | .. |
       +----+----+----+
       | x8 | y8 | z8 |
       +----+----+----+

क्या इस घन को सारणीबद्ध तरीके से प्रस्तुत करने के मात्र कार्य द्वारा "चपटा" किया जा रहा है? क्या कोई संबंध (मूल्य) उसके सारणीबद्ध प्रतिनिधित्व के समान है?

एक संबंध चर एक n-आयामी असतत स्थान में बिंदुओं के मान सेट के रूप में मानता है, जहां n संबंध विशेषताओं ("कॉलम") की संख्या है। एन-आयामी असतत स्थान के लिए, "फ्लैट" होने का क्या अर्थ है? बस बकवास, जैसा कि मैंने ऊपर लिखा है।

मुझे गलत मत समझो, यह निश्चित रूप से सच है कि SQL एक बुरी तरह से डिज़ाइन की गई भाषा है और SQL-आधारित DBMSes विशिष्टताओं और कमियों (NULLs, अतिरेक, ...) से भरे हुए हैं, विशेष रूप से बुरे वाले, DBMS-as- डंब-स्टोर प्रकार (कोई संदर्भात्मक बाधा नहीं, कोई अखंडता बाधा नहीं, ...) लेकिन इसका संबंधपरक डेटा मॉडल की काल्पनिक सीमाओं से कोई लेना-देना नहीं है, इसके विपरीत:जितना अधिक वे इससे दूर हो जाते हैं और परिणाम बदतर होता है।

विशेष रूप से, संबंधपरक डेटा मॉडल, एक बार जब आप इसे समझ लेते हैं, तो किसी भी संरचना, यहां तक कि पदानुक्रम और रेखांकन का प्रतिनिधित्व करने में कोई समस्या नहीं होती है, जैसा कि मैंने ऊपर वर्णित प्रकाशित पत्रों के संदर्भ में विस्तृत किया है। यदि आप इसकी कमियों पर प्रकाश डालते हैं तो SQL भी कुछ बेहतर खो सकता है।

"नेस्टेड सेट मॉडल" पर

मैंने बाकी उस लेख को स्किम किया और मैं इस तरह के तार्किक डिजाइन से विशेष रूप से प्रभावित नहीं हूं:यह दो अलग-अलग संस्थाओं, नोड्स को उलझाने का सुझाव देता है और लिंक , एक रिश्ते में और यह शायद अजीबता का कारण बनेगा। लेकिन मैं उस डिज़ाइन का अधिक गहन विश्लेषण करने के लिए इच्छुक नहीं हूँ, क्षमा करें।

संपादित करें: स्टीफ़न एगरमोंट ने नीचे टिप्पणी में आपत्ति की, कि " ".

अब, मेरी बात ठीक यही है कि:

यह "फ्लैट सूची मॉडल" एक फंतासी . है :सिर्फ इसलिए कि एक टेबल ("फ्लैट सूचियां") के रूप में संबंधों को दर्शाता है (प्रतिनिधित्व करता है) इसका मतलब यह नहीं है कि संबंध "फ्लैट सूचियां" हैं (एक "ऑब्जेक्ट" और इसके प्रतिनिधित्व एक ही चीज़ नहीं हैं);
एक तार्किक प्रतिनिधित्व (संबंध) और भौतिक भंडारण विवरण (क्षैतिज या लंबवत अपघटन, संपीड़न, अनुक्रमणिका (हैश, बी + पेड़, आर-पेड़, ...), क्लस्टरिंग, विभाजन, आदि) अलग हैं; संबंधपरक डेटा मॉडल के बिंदुओं में से एक (RDM ) तार्किक को "भौतिक" मॉडल से अलग करना है (उपयोगकर्ताओं और DBMSes के कार्यान्वयनकर्ताओं दोनों के लिए लाभ के साथ);
प्रदर्शन भौतिक भंडारण विवरण (कार्यान्वयन) का प्रत्यक्ष परिणाम है और नहीं तार्किक प्रतिनिधित्व का (एगरमोंट की टिप्पणी तार्किक-भौतिक भ्रम का एक उत्कृष्ट उदाहरण है। )।

आरडीएम मॉडल किसी भी तरह से कार्यान्वयन को बाधित नहीं करता है; कोई व्यक्ति टुपल्स और संबंधों को लागू करने के लिए स्वतंत्र है जैसा कि कोई फिट देखता है। संबंध जरूरी नहीं . हैं फ़ाइलें और टुपल्स जरूरी नहीं हैं एक फ़ाइल का रिकॉर्ड। ऐसा पत्राचार एक बेवकूफ प्रत्यक्ष-छवि कार्यान्वयन . है ।

दुर्भाग्य से SQL-आधारित DBMS कार्यान्वयन हैं , अक्सर, गूंगा प्रत्यक्ष-छवि कार्यान्वयन और वे विभिन्न परिदृश्यों में खराब प्रदर्शन का सामना करते हैं - OLAP ए> /ETL इन कमियों को दूर करने के लिए उत्पाद मौजूद हैं।

यह धीरे-धीरे बदल रहा है। वाणिज्यिक और मुफ्त सॉफ्टवेयर/ओपन सोर्स कार्यान्वयन हैं जो अंततः इस मूलभूत नुकसान से बचते हैं:

वर्टिका , जो .. का व्यावसायिक उत्तराधिकारी है..
C-Store:A Column-Oriented DBMS ;
MonetDB ;
LucidDB ;
Kdb एक तरह से;
आदि...

बेशक, बात यह है कि नहीं कि एक "इष्टतम" भौतिक भंडारण डिज़ाइन मौजूद होना चाहिए, लेकिन यह कि जो भी भौतिक भंडारण डिज़ाइन एक अच्छी घोषणात्मक भाषा द्वारा दूर किया जा सकता है संबंधपरक बीजगणित/कैलकुली पर आधारित (और SQL एक खराब . है उदाहरण) या अधिक सीधे तर्क प्रोग्रामिंग भाषा पर (जैसे प्रोलॉग, उदाहरण के लिए - "SQL कनवर्टर के लिए प्रोलॉग करें "प्रश्न। डेटा एक्सेस आंकड़ों (और/या उपयोगकर्ता संकेतों) के आधार पर, एक अच्छा डीबीएमएस ऑन-द-फ्लाई भौतिक भंडारण डिज़ाइन बदलना चाहिए।

अंत में, एगरमोंट की टिप्पणी में कथन " संबंधपरक मॉडल क्लाउड और प्रीवायलर के बीच निचोड़ा जा रहा है। " एक और बकवास है लेकिन मैं यहां खंडन नहीं कर सकता, यह टिप्पणी पहले से ही बहुत लंबी है।