डेटाबेस में इकाइयों को स्टोर करने का सबसे अच्छा तरीका

21

मुझे एक बड़ा (SQLServer) डेटाबेस विरासत में मिला है जिसमें सैकड़ों कॉलम हैं जो एक चीज या किसी अन्य की मात्रा का प्रतिनिधित्व करते हैं। इन मूल्यों (जैसे "गैलन", "इंच", आदि) के लिए इकाइयों को विस्तारित गुणों के MS_Description क्षेत्र में संग्रहीत किया जाता है। मैं सोच रहा हूं कि क्या इस जानकारी को संग्रहीत करने का कोई बेहतर तरीका है। मुझे लगता है कि यह प्रलेखन उद्देश्यों के लिए ठीक है, लेकिन इस डेटा के आधार पर मजबूत इकाई-रूपांतरण गणना करना मुश्किल होगा। इस बिंदु पर मैं एक आक्रामक परिवर्तन करने के लिए तैयार नहीं हूं, लेकिन अगर मुझे ऐसा करने का मौका मिलता है, तो इस संबंध में अनुशंसित सर्वोत्तम अभ्यास क्या है? विकल्प, मेरे सिर के ऊपर, शामिल हो सकते हैं:

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

अद्यतन: @Todd एवरेट के उत्तर को पढ़ने के बाद, एक संभावित समाधान मेरे पास आया, इसलिए मैं आगे जा रहा हूं और अपने स्वयं के प्रश्न का उत्तर दूंगा। (निचे देखो)

sql-server database-design metadata

— kmote
स्रोत

सबसे अच्छा अभ्यास एक एकल माप प्रणाली है जिसका उपयोग सार्वभौमिक और लगातार पूरे अनुप्रयोग में किया जाता है। एसआई चुनाव की प्रणाली होगी। अन्य प्रणालियों में मूल्यों को लोडिंग या प्रस्तुति परत के दौरान परिवर्तित किया जाएगा, जहां प्रत्येक उपयोगकर्ता अपना पसंदीदा सेट चुन सकता है।

— माइकल ग्रीन

12

चूंकि आप सैकड़ों स्तंभों का उल्लेख करते हैं, इसलिए मैं एक ईएवी डिजाइन पर विचार करूंगा । जबकि जो सेल्को इसके खिलाफ चेतावनी देता है , मुझे लगता है कि यह आपके उपयोग के मामले में लागू हो सकता है। ऐसा लगता है कि आपकी सभी "राशियाँ" संख्याएँ हैं, इसलिए आप जो भी वर्णन करते हैं और हर "मूल्य" को एक स्ट्रिंग बनाने की आवश्यकता से बचें। यदि सभी राशियाँ पूर्ण संख्याएँ हैं तो भी यह बेहतर होगा, लेकिन यदि कुछ दशमलव हैं तो यह भी काम कर सकती है। माप की इकाइयों को देखते हुए, आप एक कदम आगे बढ़ सकते हैं और डेविड हे द्वारा इस लेख के आधार पर एक "सार्वभौमिक डेटा मॉडल" शैली मॉडल को लागू कर सकते हैं और उनकी पुस्तक डेटा मॉडल पैटर्न: कॉन्वेंट ऑफ़ थॉट में भी उल्लिखित है।। इस मॉडल को कॉन्फ़िगर करने का अतिरिक्त लाभ यह है कि "राशियाँ" किस "चीजों" पर लागू होती हैं यदि आपको इसकी आवश्यकता है। पृष्ठ 162 पर पुस्तक में दिखाया गया एक अतिरिक्त कदम माप रूपांतरण तालिका की एक इकाई है जिसे आप माप की विभिन्न इकाइयों के बीच परिवर्तित करने के लिए उपयोग कर सकते हैं। यहाँ एक उदाहरण है:

UOM Conversion              

UOM From    UOM To        Cal Step  Operator Factor Constant
Kilograms   Pounds        1         *        2.2
Celsius     Fahrenheit    1         *        1.8
Celsius     Fahrenheit    2         +               32

यह कहता है कि Kg से Lb में बदलने के लिए पहला कदम Kg को 2.2 से गुणा करना है। यदि कोई रूपांतरण में एक स्थिर मान और कई चरणों को बनाने की क्षमता शामिल है, तो एक स्थिर भी है। इसलिए जब सेल्सियस को फ़ारेनहाइट में परिवर्तित करते हुए आप सेल्सियस को 1.8 से गुणा करते हैं और फिर 32 जोड़ते हैं। कुंजी यूओएम, यूओएम और गणना चरण से होगी।

यह मेरा 2 सेंट का मूल्य है। मुझे उम्मीद है कि इन संदर्भों से आपको कुछ अच्छा खाना मिलेगा, क्या आपको कभी मौजूदा डिजाइन पर रिबूट करने का मौका मिलना चाहिए।

— टोड एवरेट
स्रोत

विचार के लिए कुछ बहुत दिलचस्प भोजन के लिए धन्यवाद - मैंने बहुत कुछ सीखा। हालांकि, मुझे नहीं लगता कि ईएवी मेरे मामले में उपयुक्त मॉडल है (यदि मैं आपके सुझाव को सही ढंग से समझता हूं) क्योंकि, हालांकि हमारे पास 100 कॉलम हैं, वे किसी भी तरह से विरल नहीं हैं। हालाँकि, यह DID संबंधित विचार को स्पार्क करता है (मेरी मूल पोस्ट में अद्यतन देखें)।

— kmote

आपका विचार मुझे बहुत अच्छा लगता है - मैं इसके साथ किसी भी मुद्दे के बारे में नहीं सोच सकता जो आपने पहले ही बताया था। लेकिन अगर कॉलम का नाम बदला / बदला जा सकता है जो किसी भी डिजाइन में एक समस्या होगी। यह तब होता है जब सहयोग मज़ेदार होता है - एक ऐसा विचार जो हम दोनों में से किसी ने भी शुरू करने के बारे में नहीं सोचा था!

— टॉड एवरेट

8

सारा काम।

ध्यान दें कि दूसरे मामले में, आप सेब और संतरे नहीं जोड़ सकते हैं, और इसलिए डेटा असाधारण रूप से गलत व्याख्या के अधीन है।

यह भी ध्यान दें कि रूपांतरण बहुत सुरक्षित नहीं हो सकते हैं और गोल त्रुटि, अतिवृद्धि आदि के लिए अतिसंवेदनशील होते हैं।

इसके अलावा, विशिष्ट गुरुत्व और तापमान जैसे भौतिक मुद्दे हैं। 20 गैलन पानी को पाउंड में बदलने से आपको पानी के घनत्व को जानना होगा। लेकिन तापमान के साथ पानी का घनत्व बदल जाता है, इसलिए आपको माप या तापमान के समान ही घनत्व के बारे में जानना होगा या वॉल्यूम सुधार कारक का उपयोग करना होगा।

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

एक अन्य विकल्प अलग-अलग मूल मापों के अलावा नियत इकाइयों (हमेशा किलोग्राम और मीटर) में विहित संस्करणों को संग्रहीत करना है। निर्धारित इकाइयों पर अलग-अलग संचालन ठीक होना चाहिए (उदाहरण के लिए, आप तापमान नहीं जोड़ेंगे), लेकिन आप मूल माप नहीं खोते हैं।

— कैड रूक्स
स्रोत

1

आपके द्वारा उल्लिखित संभावित "गलत व्याख्या" इस डेटाबेस की वर्तमान वास्तुकला के बारे में मेरे द्वारा बताई गई चिंताओं में से एक है - और कुछ मैं इसे कम करने का तरीका जानने की कोशिश कर रहा हूं।

— '21

1

स्तंभ-नाम समाधान के संभावित दोष के बारे में महान बिंदु।

— 29:12

1

@kmote यह एक साधारण समस्या नहीं है - हमारे पास ऐसी रिपोर्टें हैं जहां व्यक्तिगत लेनदेन में अलग-अलग मूल माप इकाइयाँ हो सकती हैं, लेकिन एक कुल भी है - जो एक उपयोगकर्ता-चयनित इकाई में रूपांतरण के बाद कुल है।

— कैड रूक्स

7

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

एक बार जब आपके पास मानक आधार इकाइयों में सभी डेटा होते हैं, तो डेटाबेस में इकाई को स्टोर करने की कोई आवश्यकता नहीं होती है, क्योंकि यह अब एक प्रणाली व्यापक धारणा है। प्रत्येक इकाई प्रकार के लिए आवश्यक प्रदर्शित इकाइयाँ (उदाहरण के लिए प्रदर्शित करने के लिए मिमी, इंच, सेमी, मीटर लंबाई के लिए) एक एप्लिकेशन / क्लाइंट डोमेन समस्या बन जाती है, जिसे स्थानीय भंडारण में बचाया जा सकता है।

विभिन्न समर्थित इकाइयों के बीच परिवर्तित करने के लिए इकाई रूपांतरण तालिकाओं को आपके आवेदन के भीतर हार्डकोड किया जा सकता है, क्योंकि माप की नई इकाइयां बहुत कम बदलती हैं।

एनबी एक अन्य मुद्दे से संबंधित समाधान है जब एक डेटाबेस में टाइमस्टैम्प को स्टोर करने के लिए हमेशा उन्हें 'आधार' इकाई - यूटीसी में संग्रहीत किया जाता है ।

विषय पर एक और संबंधित प्रश्नोत्तर ...

/programming/12977021/best-practice-for-storing-weights-in-a-sql-database
इसमें कुछ अच्छी जानकारी शामिल है कि फ्लोटिंग पॉइंट कॉलम प्रकार का उपयोग करना वास्तविक दुनिया माप को संग्रहीत करने के लिए जाने का सबसे अच्छा तरीका क्यों है।

— dodgy_coder
स्रोत

5

चूंकि किसी भी इकाई को सूत्र के साथ उसी प्रकार की दूसरी इकाई में परिवर्तित किया जा सकता है:

y = ((x + xOffset) * multiplicand / denominator) + yOffset

मैं एक तालिका बनाऊंगा जिसमें यूनिट प्रकार और इन 4 मान शामिल हैं।

From Unit     To Unit      Unit Type    From Offset    Multiplicand    Denominator    To Offset
'milligrams'  'grams'      'mass'       0              1               1000           0
'grams'      'kilograms'   'mass'       0              1               1000           0
'grams'      'ounces'      'mass'       0              100000          2835           0
'ounces'     'pound'       'mass'       0              1               16             0

सभी मापों को जोड़े जाने के बाद, जिनके आप परिवर्तित होने की संभावना है और सूची के दोनों ओर हैं, एक क्वेरी चलाएँ जहाँ आप व्युत्क्रम ऑपरेशन को केवल ऑफ़सेट्स और स्वैपिंग मल्टीप्लेन्ड और डिनोमिनेटर और टू यूनिट और यूनिट से नकारते हैं।

सभी प्रकारों के बीच रूपांतरण जोड़ने के लिए, एक क्रॉस ज्वाइन कुछ फिल्टर के साथ रहने वाले रूपांतरण सम्मिलित कर सकते हैं।

— peroyhav
स्रोत

3

@ टोड एवरेट के उत्तर को पढ़ने के बाद, एक समाधान मेरे पास हुआ, इसलिए मैं आगे जा रहा हूं और अपने स्वयं के प्रश्न का उत्तर दूंगा। क्या मुझे लगता है कि मैं क्या करने जा रहा हूँ एक अलग बनाने के लिए है ColumnUnitsचार स्तंभों के साथ तालिका,: Schema, Table, Column, UnitsID(जहां UnitsID FK एक अलग करने के लिए है UnitsOfMeasureइस प्रकार माप की उसके संबंधित यूनिट के लिए किसी भी दिए गए स्तंभ मानचित्रण टेबल),। जाहिर है कि इस विचार का सबसे बड़ा पहलू यह है कि डेवलपर्स को इस तालिका को संपादित करने के लिए याद रखना होगा जब भी वे किसी स्तंभ या तालिका का नाम बदलते हैं [ शायद एक डीडीएल ट्रिगर का उपयोग करें ? ], अन्यथा सिस्टम टूट जाएगा। लेकिन यह मानना कि इस तरह के नामकरण दुर्लभ हैं, और देव-दुकान छोटी (सिर्फ एक व्यक्ति, मेरे मामले में), यह वास्तुकला व्यावहारिक होनी चाहिए। लाभ यह है कि वर्तमान डीबी में कोई भी आक्रामक परिवर्तन नहीं किया जाना है, और मुझे केवल प्रत्येक कॉलम के लिए एक बार मूल्य को स्टोर करना होगा, बल्कि पंक्ति के अनुसार एक बार मेरे मूल पोस्ट में मेरे दूसरे विकल्प की आवश्यकता होगी।

— kmote
स्रोत

दिलचस्प पहेली ... और दिलचस्प विचार आपके पास है। आपके विचार से क्वेरी करना आसान हो जाएगा, लेकिन लगता है कि बहुत कुछ हासिल नहीं होगा। आपने संदर्भ डेटा को किसी अन्य स्थान पर स्थानांतरित कर दिया है। इस डिजाइन के बारे में मुझे सबसे ज्यादा परेशान करता है

— सर स्वियर्स-ए-लॉट

... यह है कि यदि किसी आइटम में अधिक विशेषताएँ हैं, तो भी आपको अधिक कॉलम जोड़ने की आवश्यकता है। इस कारण से मुझे ev डिज़ाइन के @todd everett के सुझाव पसंद हैं।

— सर स्वियर्स-ए-लॉट