टेबल डिज़ाइन विकल्प?

Question

मेरे पास एक ऐसा एप्लिकेशन है जो उपयोगकर्ता इंटरैक्शन (उपयोगकर्ता इनपुट नहीं) के आधार पर डेटा भेजता है। भेजा गया डेटा एक पूर्णांक, स्ट्रिंग, दिनांक, या बूलियन मान हो सकता है। 140 कुंजी हैं। हम एक समय में 1 कुंजी मूल्य जोड़ी से कहीं भी 140 हो सकते हैं।

हम सब कुछ स्टोर करना चाहते हैं लेकिन आवेदन के भीतर केवल 140 कुंजी में से 20 का उपयोग करेंगे। शेष का उपयोग बाद में ऑडिट ट्रेल के लिए किया जाएगा - इसलिए हमें अभी भी उन्हें स्टोर करने की आवश्यकता है।

इस डेटा का उपयोग यह तय करने के लिए किया जाता है कि उपयोगकर्ता को कहां जाना है, इसलिए इसे छात्र आईडी द्वारा रिकॉर्ड तक पहुंचने और मिलीसेकंड के भीतर 20 या तो विकल्पों को खींचने की आवश्यकता है। डेटा की अरबों पंक्तियां हो सकती हैं (यह 20,000 से अधिक उपयोगकर्ताओं के साथ मौजूदा एप्लिकेशन में अपग्रेड है) इसलिए प्रदर्शन महत्वपूर्ण है। जब भी वे एप्लिकेशन तक पहुंचते हैं तो उपयोगकर्ता एक नई पंक्ति उत्पन्न करता है।

उदाहरण डेटा:

Score:1 
ID:3212 
IsLast:False 
Action:Completed 

मैं ऐसा करने के तरीके और कुछ मदद की तलाश में है, जिस पर सबसे अच्छा है या एक तिहाई एक बेहतर विकल्प विकल्प है पर 2 विचार है।

विकल्प 1:

मेरा पहला विचार मूल्य के लिए एक कॉलम का उपयोग करने के रूप में एक स्ट्रिंग तो संभव डेटा प्रकार के एक लुक-अप तालिका जब मूल्य उपयोग के लिए कास्ट किए जाने की आवश्यकता का उपयोग करना पड़ रहा है।

value  | dataType 
----------------------- 
"1"   | int 
"Completed" | string 

जबकि डेटा भेजा जा रहा है उपयोगकर्ता उत्पन्न नहीं हुआ है, मुझे पता है कि इस विधि में कहीं कहीं गॉचा होना चाहिए। ऐसा करने का एकमात्र कारण यह है कि हम नहीं जानते कि कौन सी कुंजी: जोड़ी भेजी जाएगी (तिथि और आईडी के बाहर) और कुछ कॉलम से अधिक से बचने की कोशिश कर रहा है।

SO प्रश्न How to Handle Unknown Data Type in one Table इसी तरह के विचार का उपयोग करता है।

विकल्प 2: - प्रत्येक कुंजी के लिए एक

अन्य समाधान 140 कॉलम है। हालांकि, उत्पन्न डेटा की मात्रा बहुत बड़ी है (पंक्तियों के अरबों) ताकि इस डेटा को कॉल करना पर्याप्त तेज़ न हो - मुझे नहीं लगता।

तकनीकी विवरण: यह SQL सर्वर 2008 का उपयोग कर रहा है - R2 DotNet C# और रिपोर्टिंग सेवाओं के साथ नहीं।

क्या मुझे यहां कुछ याद आ रहा है - प्रदर्शन के लिए इस तालिका को बनाने का सबसे अच्छा तरीका क्या है?

Answer 1

अपने डेटा को लंबवत रूप से विभाजित करें। एक तालिका में नेविगेशन नियंत्रण के लिए आवश्यक 20 कुंजियां रखें, एक पंक्ति में सभी 20, पीके के साथ जो उपयोगकर्ता इंटरैक्शन (कॉलिट कहते हैं, InteractionId) की पहचान करता है। पहली तालिका के पीके (InteractionId, प्लस KeyTypeId के आधार पर समग्र प्राथमिक कुंजी के साथ, अन्य 120 मानों को अन्य तालिका में रखें, यह पहचानने के लिए कि 120 संभावित कुंजी मूल्य जोड़े किस मान के लिए हैं। इस दूसरे तालिका में सभी मानों को स्टोर करें स्ट्रिंग्स के रूप में, KeyTypes नामक एक तीसरी लुकअप टेबल में, KeyTypeId, KeyTypeName, और KeyValueDataType स्टोर करें ताकि आपके कोड को यह पता चल सके कि स्ट्रिंग मान को स्ट्रिंग, डेटाटाइम, एक पूर्णांक या एक के रूप में ठीक से आउटपुट करने के तरीके को कैसे डाला जाए। दशमलव मूल्य या जो कुछ भी ...

पहली तालिका को अधिक बार उपयोग किया जाएगा, और इसलिए इसमें केवल वे मान होते हैं जो अनुप्रयोग की नेविगेशन कार्यक्षमता को पंक्तियों को संकुचित रखने के लिए अधिक बार उपयोग की आवश्यकता होती है, जो प्रति पृष्ठ अधिक पंक्तियों की अनुमति देता है, और डिस्क IO को कम करता है। सभी पंक्तियों को एक पंक्ति में रखकर पंक्ति को छोटा (~ 1/20th बड़ा) गिनती होगी, इंडेक्स की गहराई को कम करने के लिए प्रत्येक एक्सेस के लिए प्रदर्शन करने की आवश्यकता होगी।

अन्य सभी 120 कुंजी-मानों वाली अन्य तालिका को अक्सर एक्सेस नहीं किया जाएगा, इसलिए इसकी संरचना को प्रदर्शन के बजाए तार्किक सादगी के लिए अनुकूलित किया जा सकता है।

Answer 2

वैसे यह दोनों विचारों का परीक्षण करने के लिए काफी आसान होना चाहिए, लेकिन विकल्प 1 पर एक बदलाव मुझे पसंद करता है। एसक्यूएल सर्वर जैसे आरडीबीएमएस लंबे, संकीर्ण तालिकाओं को पसंद करते हैं (यानी कम कॉलम लेकिन बहुत सारी पंक्तियां)।

मैं आगे नहीं जाऊंगा क्योंकि ऐसा लगता है कि चार्ल्स ने पूरी तरह से समझदार सुझाव के साथ इसे हराया है।

Answer 3

असल में, आप मर्ज करने के सुझावों अब तक की पेशकश की हो सकती है:

नौवहन नियंत्रण के लिए आवश्यक 20 कुंजी के साथ एक तालिका बनाएं, प्लस एक प्राथमिक कुंजी के लिए एक स्तंभ, प्लस एक स्तंभ है कि स्टोर करने के लिए एक XML डेटा प्रकार है शेष संभव डेटा। फिर आप एक डीटीडी बना सकते हैं जो प्रत्येक कुंजी के लिए डेटा प्रकारों को संभालता है, साथ ही आवश्यकतानुसार कुछ कुंजियों पर बाधा डालता है।