मैंने एक युग पहले इकाइयों को संभालने के लिए एक डेटाबेस उप-स्कीमा तैयार किया था (ठीक है, मैं थोड़ा अतिशयोक्ति करता हूं; यह लगभग 20 साल पहले था, हालांकि)। सौभाग्य से, इसे केवल साधारण द्रव्यमान, लंबाई, समय आयामों से निपटना था - तापमान, या विद्युत प्रवाह, या चमक, आदि नहीं। बल्कि कम सरल खेल का मुद्रा पक्ष था - एक मुद्रा के बीच परिवर्तित करने के असंख्य तरीके थे और दूसरा दिनांक, मुद्रा और अवधि के आधार पर जिस पर रूपांतरण दर मान्य थी। इसे भौतिक इकाइयों से अलग से नियंत्रित किया गया था।
मूल रूप से, मैंने एक 'आईडी' कॉलम के साथ एक टेबल 'उपाय' बनाया, इकाई के लिए एक नाम, संक्षेप, और आयाम एक्सपोनेंट्स का एक सेट - द्रव्यमान, लंबाई, समय के लिए प्रत्येक। यह 'वॉल्यूम' (लंबाई =3, द्रव्यमान =0, समय =0) जैसे नामों से पॉप्युलेट हो जाता है, 'घनत्व' (लंबाई =3, द्रव्यमान =-1, समय =0) - और इसी तरह।
इकाइयों की एक दूसरी तालिका थी, जिसने एक माप की पहचान की और फिर एक विशेष माप द्वारा उपयोग की जाने वाली वास्तविक इकाइयाँ। उदाहरण के लिए, बैरल, और घन मीटर, और प्रासंगिकता की अन्य सभी प्रकार की इकाइयाँ थीं।
एक तीसरी तालिका थी जो विशिष्ट इकाइयों के बीच रूपांतरण कारकों को परिभाषित करती थी। इसमें दो इकाइयाँ शामिल थीं और गुणक रूपांतरण कारक जिसने इकाई 1 को इकाई 2 में बदल दिया। यहाँ सबसे बड़ी समस्या रूपांतरण कारकों की गतिशील सीमा थी। यदि U1 से U2 में रूपांतरण 1.234E+10 है, तो उलटा एक छोटी संख्या (8.103727714749e-11) है।
तापमान के बारे में S.Lott की टिप्पणी दिलचस्प है - हमें उनसे निपटने की ज़रूरत नहीं थी। एक संग्रहीत कार्यविधि ने इसे संबोधित किया होगा - हालांकि एक संग्रहीत कार्यविधि को सिस्टम में एकीकृत करना मुश्किल हो सकता है।
मैंने जिस योजना का वर्णन किया है, उसमें अधिकांश रूपांतरणों को एक बार वर्णित करने की अनुमति दी गई है (जिसमें काल्पनिक इकाइयां जैसे कि प्रति पखवाड़े, या कम काल्पनिक लेकिन समान रूप से अस्पष्ट हैं - संयुक्त राज्य अमेरिका के बाहर - जैसे एकड़-फीट), और रूपांतरणों को मान्य किया जा सकता है (उदाहरण के लिए, दोनों रूपांतरण कारक तालिका में इकाइयों का माप समान होना चाहिए)। इसे अधिकांश अन्य इकाइयों को संभालने के लिए बढ़ाया जा सकता है - हालांकि आयाम रहित इकाइयां जैसे कोण (या ठोस कोण) कुछ दिलचस्प समस्याएं पेश करते हैं। एक सहायक कोड था जो मनमाना रूपांतरणों को संभाल सकता था - या जब रूपांतरण का समर्थन नहीं किया जा सकता था तो एक त्रुटि उत्पन्न करता था। इस प्रणाली का एक कारण यह था कि विभिन्न अंतरराष्ट्रीय संबद्ध कंपनियां अपने स्थानीय रूप से सुविधाजनक इकाइयों में अपने डेटा की रिपोर्ट करेंगी, लेकिन मुख्यालय प्रणाली को मूल डेटा को स्वीकार करना होगा और फिर भी परिणामी एकत्रित डेटा को उन इकाइयों में प्रस्तुत करना होगा जो प्रबंधकों के अनुकूल हों - जहां अलग-अलग प्रबंधक प्रत्येक उनकी रिपोर्ट के लिए सर्वश्रेष्ठ इकाइयों के बारे में उनका अपना विचार था (उनकी राष्ट्रीय पृष्ठभूमि और मुख्यालय में कर्तव्य की लंबाई के आधार पर)।
