लुकअप टेबल्स का उचित उपयोग


25

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

मान लीजिए कि मेरे पास एक कर्मचारी है जिसे कर्मचारी कहा जाता है:

ID  LName   FName   Gender  Position
1   Doe     John    Male    Manager
2   Doe     Jane    Female  Sales
3   Smith   John    Male    Sales

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

ID  Position
1   Manager
2   Sales

लेकिन इससे पहले कि यह असहनीय हो जाए, मैं सूचनाओं को छोटी लुकअप टेबलों में कैसे तोड़ सकता हूं? मैं एक जेंडर टेबल बना सकता था और पुरुष के लिए 1 और एक अलग लुकअप टेबल में महिला के लिए 2 संवाददाता हो सकता था। मैं भी टेबल में LNames और FNames डाल सकता है। सभी "जॉन" प्रविष्टियों को 1 की एक विदेशी कुंजी के साथ बदल दिया जाता है जो FName तालिका की ओर इशारा करती है जो कहती है कि 1 की ID जॉन से मेल खाती है। यदि आप इस खरगोश के छेद को इस तरह से बहुत नीचे जाते हैं, हालांकि, आपकी कर्मचारी तालिका फिर विदेशी कुंजियों की गड़बड़ी से कम हो जाती है:

ID  LName   FName   Gender  Position
1   1       1       1       1
2   1       2       2       2
3   2       1       1       2

हालांकि यह किसी सर्वर को प्रोसेस करने के लिए अधिक कुशल नहीं हो सकता है, लेकिन यह निश्चित रूप से एक सामान्य व्यक्ति के लिए अपठनीय है जो इसे बनाए रखने की कोशिश कर रहा हो और इसे एक्सेस करने की कोशिश करने वाले एप्लिकेशन डेवलपर के लिए इसे और अधिक कठिन बना देता है। तो, मेरा असली सवाल यह है कि कितनी दूर है? क्या इस तरह की चीज़ों के लिए "सर्वोत्तम अभ्यास" या कहीं दिशा-निर्देश का एक अच्छा सेट है? मुझे कोई भी जानकारी ऑनलाइन नहीं मिल रही है जो वास्तव में इस विशेष मुद्दे के लिए दिशानिर्देशों के एक अच्छे, प्रयोग करने योग्य सेट के नीचे है। डेटाबेस डिज़ाइन मेरे लिए पुरानी टोपी है लेकिन GOOD डेटाबेस डिज़ाइन बहुत नया है इसलिए मेरे सिर पर तकनीकी उत्तर हो सकते हैं। किसी भी सहायता की सराहना की जाएगी!


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

1
लिंग को हमेशा 2 मानों के लिए निर्धारित नहीं किया जा सकता है! अब जब हमारे पास लिंग परिवर्तन है, तो यह कहना है कि एक आवेदन के लिए अतिरिक्त श्रेणियों की आवश्यकता नहीं हो सकती है जैसे कि 'जन्म लेने वाले पुरुष अब महिला' या 'जन्म लेने वाली महिला' पुरुष '।

@ माइक, अच्छी टिप्पणी!
वाल्टर मिती

मेरी दुकान में विचारक केवल चार विकल्पों के बाद ही रुकने में सक्षम थे, पुरुष, महिला, ट्रांसजेंडर, खुलासा नहीं करेंगे।
केविन्स्की

जवाबों:


22

लेकिन इससे पहले कि यह असहनीय हो जाए, मैं सूचनाओं को छोटे लुकअप तालिकाओं में कैसे तोड़ सकता हूं? मैं एक जेंडर टेबल बना सकता था और पुरुष के लिए 1 और एक अलग लुकअप टेबल में महिला के लिए 2 संवाददाता हो सकता था।

आप दो अलग-अलग मुद्दों को मिला रहे हैं। एक मुद्दा "लुकअप" तालिका का उपयोग है; अन्य सरोगेट कुंजी (आईडी नंबर) का उपयोग है।

इस तालिका से शुरू करें।

ID  LName   FName   Gender  Position
1   Doe     John    Male    Manager
2   Doe     Jane    Female  Sales
3   Smith   John    Male    Sales

आप इस तरह के पदों के लिए एक "लुकअप" तालिका बना सकते हैं।

create table positions (
  pos_name varchar(10) primary key
);

insert into positions
select distinct position 
from employees;

alter table employees
add constraint emp_fk1
foreign key (position) 
  references positions (pos_name);

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

"लुकअप" टेबल का उपयोग करने से यह उबलता है: क्या आपके आवेदन को इनपुट मूल्यों पर नियंत्रण की आवश्यकता है जो एक विदेशी कुंजी संदर्भ प्रदान करता है? यदि ऐसा है, तो आप हमेशा "लुकअप" तालिका का उपयोग कर सकते हैं। (चाहे वह सरोगेट कुंजी का उपयोग करता हो।)

कुछ मामलों में, आप डिज़ाइन समय पर उस तालिका को पूरी तरह से आबाद कर पाएंगे। अन्य मामलों में, उपयोगकर्ताओं को उस समय में उस तालिका में पंक्तियों को जोड़ने में सक्षम होना चाहिए। (और आपको नए डेटा की समीक्षा करने के लिए संभवतः कुछ प्रशासनिक प्रक्रियाओं को शामिल करना होगा।) लिंग, जिसमें वास्तव में एक आईएसओ मानक है , डिजाइन समय पर पूरी तरह से आबाद हो सकता है। अंतर्राष्ट्रीय ऑनलाइन उत्पाद ऑर्डर के लिए स्ट्रीट नाम संभवत: रन टाइम पर जोड़े जाएंगे।


2
मुझे नहीं पता था कि आप वह सब कर सकते हैं! जिस तरह से आपकी विधि काम करती है वह थोड़े सुंदर है। धन्यवाद!
ब्रैड टर्नर

4
मैं डीबीए स्टैक एक्सचेंज में शामिल हो गया ताकि मैं इस जवाब को वोट कर सकूं। यह सुंदर है और मेरे साथ कभी नहीं हुआ। धन्यवाद!
सिंडीह

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

8

आपकी कर्मचारी तालिका में, मुझे केवल "स्थिति" के लिए एक लुकअप करना होगा क्योंकि यह डेटा का एक सीमित सेट है जो विस्तार कर सकता है।

  • लिंग आत्म वर्णन (कहना Mया F) है, 2 मूल्यों तक सीमित है, और इसे एक CHECK बाधा के साथ लागू किया जा सकता है। आप नए लिंग नहीं जोड़ेंगे (राजनैतिक शुद्धता को अनदेखा करते हुए)
  • पहला नाम "जॉन" डेटा का एक सीमित, प्रतिबंधित सेट का हिस्सा नहीं है: डेटा का संभावित सेट प्रभावी रूप से असीम के बिंदु के लिए बड़े पैमाने पर है, इसलिए इसे लुकअप नहीं होना चाहिए

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

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

चलो एक नया कॉलम "वेतन मुद्रा" जोड़ें। मैं यहां CHF, GBP, EUR, USD आदि की कुंजी के साथ लुकअप टेबल का उपयोग करूंगा: मैं सरोगेट कुंजी का उपयोग नहीं करूंगा। यह जेंडर की तरह एक CHECK बाधा के साथ प्रतिबंधित किया जा सकता है, लेकिन यह स्थिति की तरह डेटा का एक सीमित अभी तक विस्तार योग्य सेट है। मैं इसका उदाहरण देता हूं कि मैं प्राकृतिक कुंजी का उपयोग करूंगा भले ही वह चार (कर्मचारी) डेटा की एक लाख पंक्तियों में दिखाई दे रही हो, भले ही वह चार (3) हो लेकिन बाद में संकेत नहीं देता

इसलिए, संक्षेप में, आप लुकअप टेबल का उपयोग करते हैं

  1. जहां आपके पास एक परिमित, अभी तक एक स्तंभ में विस्तार योग्य सेट डेटा है
  2. जहाँ आत्म वर्णन नहीं है
  3. डेटा संशोधन विसंगतियों से बचने के लिए

1
एक लुकअप टेबल में लिंग डालने का एक संभावित कारण स्थानीयकरण है।
a_horse_with_no_name

1
"लिंग ... (एम या एफ कहें), 2 मूल्यों तक सीमित ... राजनीतिक शुद्धता के बोल को अनदेखा करना" - विडंबना यह है कि यह बहुत ही राजनीतिक शुद्धता है जो आपको घृणित लगती है जो लोगों को गलत तरीके से "लिंग" का कारण बनाती है (' मर्दाना ',' स्त्रीलिंग ') जब उनका मतलब "सेक्स" (' पुरुष ',' महिला ') होता है। यदि संदर्भ व्याकरणिक लिंग है तो आमतौर पर दो से अधिक मूल्य होते हैं। यदि संदर्भ नवजात शिशु के लिंग को रिकॉर्ड कर रहा है तो कम से कम चार मूल्य हैं ('आधिकारिक तौर पर मूल्यांकन नहीं किया गया है' और 'आधिकारिक मूल्यांकन अनिर्णायक था')। ps मेरा मतलब कठोर नहीं है, मैंने विडंबना का आनंद लिया :)
onedaywhen

4
@onedaywhen: "Sex" नामक एक कॉलम के लिए सही मूल्य "हां कृपया" है। जब तक आप ब्रिटिश नहीं हैं
gbn

शब्द "विसंगतियों" का दुरुपयोग यहां किया जा रहा है क्योंकि इस शब्द का सामान्यीकरण से संबंधित एक विशेष अर्थ है, और लिंक अनुचित है।
दार्शनिक

5

जवाब एक "यह निर्भर करता है" है। बहुत संतोषजनक नहीं है लेकिन डिजाइन को आगे बढ़ाने और खींचने में कई प्रभाव हैं। यदि आपके पास ऐप प्रोग्रामर हैं, तो डेटाबेस को एक ऐसी संरचना तैयार करते हैं, जैसे आप उनके लिए काम का वर्णन करते हैं क्योंकि ORM जटिलता को छुपाता है। जब आप रिपोर्ट लिखेंगे और पता पाने के लिए दस तालिकाओं से जुड़ना होगा, तो आप अपने बाल खींच रहे होंगे।

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

किसी पसंदीदा उद्धरण का पुन: उपयोग करने के लिए

"एक बुद्धिमान व्यक्ति ने मुझे एक बार कहा था" जब तक यह दर्द होता है, तब तक इसे सामान्य करें जब तक यह काम नहीं करता है। "

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

एक वास्तविक प्रणाली से अत्यधिक सामान्यीकृत तालिकाओं के इस संक्षिप्त उदाहरण को लें

CREATE TABLE PROPERTY
(ID                          NUMBER(9)           NOT NULL);

CREATE TABLE PROPERTY_TYPE
(ID                          NUMBER(9)           NOT NULL);

CREATE TABLE PROPERTY_LOCALE 
PROPERTY_ID                  NUMBER(9)           NOT NULL,
(LOCALE_ID                   NUMBER(9)           NOT NULL,  --language 
VALUE                        VARCHAR2(200)       NOT NULL);

CREATE TABLE PROPERTY_DEPENDENCY
(PROPERTY_ID                 NUMBER(9)           NOT NULL,
 PARENT_PROPERTY_ID          NUMBER(9)                   ,
 PROPERTY_TYPE_ID            NUMBER(9)           NOT NULL);

इन तालिकाओं में एकल गुणों और माता-पिता की बाल संपत्तियों की एक लिंक की गई सूची है और वे यहाँ उपयोग किए जाते हैं

  CREATE TABLE CASE_PROPERTY
  (ID                        NUMBER(9)           NOT NULL,
  PARENT_ID                  NUMBER(9),
  CASE_ID                    NUMBER(9)           NOT NULL,
  PROPERTY_ID                NUMBER(9),
  PROPERTY_TYPE_ID           NUMBER(9)           NOT NULL);

यह ठीक लग रहा है: एक मामले में एक प्रॉपर्टी_ड के साथ सभी मामले प्राप्त करें

से लेने के लिए एक सूची मिलती है

 Select pl.value, pd.property_id
 from property_locale pl, property_dependency pd
 where pl.property_id = pd.property_id
 and pd.property_type_id = 2;  --example number

अब किसी मामले के सभी गुणों का चयन करने का प्रयास करें यदि उसमें 3 और 4 और 5 के गुण_ हैं, या नहीं ...

SELECT   cp2.case_id,
         (SELECT   pl.VALUE
            FROM   case_property cp, property_locale pl
           WHERE       cp.property_id = pl.property_id
                   AND CP.PROPERTY_TYPE_ID = 2
                   AND pl.locale_id = 2
                   AND cp.case_id = cp2.case_id)
            AS VALUE1,
         (SELECT   pl.VALUE
            FROM   case_property cp, property_locale pl
           WHERE       cp.property_id = pl.property_id
                   AND CP.PROPERTY_TYPE_ID = 34
                   AND pl.locale_id = 2
                   AND cp.case_id = cp2.case_id)
            AS VALUE2,
         (SELECT   pl.VALUE
            FROM   case_property cp, property_locale pl
           WHERE       cp.property_id = pl.property_id
                   AND CP.PROPERTY_TYPE_ID = 4
                   AND pl.locale_id = 2
                   AND cp.case_id = cp2.case_id)
            AS VALUE3
  FROM   case_property cp2
 WHERE   cp2.case_id = 10293  

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

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


5
आईडी नंबरों का सामान्यीकरण से कोई लेना-देना नहीं है। सिर्फ इसलिए कि हर तालिका में एक आईडी संख्या है इसका मतलब यह नहीं है कि यह 5NF या 3NF में भी है। इसका सिर्फ इतना मतलब है कि आपको उस तालिका से उपयोग करने योग्य डेटा प्राप्त करने के लिए बहुत सारे योग करने होंगे।
माइक शेरिल 'कैट रिकॉल'
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.