2009-10-15 4 views
8

मैंने एक नई परियोजना शुरू की है और उनके पास एक सामान्यीकृत डेटाबेस है। सबकुछ जो लुकअप हो सकता है उसे लुकअप टेबल पर विदेशी कुंजी के रूप में संग्रहीत किया जाता है। यह सामान्य और ठीक है, लेकिन मैं सरलतम प्रश्नों के लिए 5 टेबल जोड़ता हूं।सैनिटी या प्रदर्शन के लिए denormalizing?

from va in VehicleActions 
    join vat in VehicleActionTypes on va.VehicleActionTypeId equals vat.VehicleActionTypeId 
    join ai in ActivityInvolvements on va.VehicleActionId equals ai.VehicleActionId 
    join a in Agencies on va.AgencyId equals a.AgencyId 
    join vd in VehicleDescriptions on ai.VehicleDescriptionId equals vd.VehicleDescriptionId 
    join s in States on vd.LicensePlateStateId equals s.StateId 
    where va.CreatedDate > DateTime.Now.AddHours(-DateTime.Now.Hour) 
    select new {va.VehicleActionId,a.AgencyCode,vat.Description,vat.Code, 
vd.LicensePlateNumber,LPNState = s.Code,va.LatestDateTime,va.CreatedDate} 

मैं यह सुझाव देना चाहता हूं कि हम कुछ सामानों को denormaize। राज्य कोड की तरह। मुझे अपने जीवनकाल में बदल रहे राज्य कोड नहीं दिखते हैं। 3-अक्षर एजेंसी कोड के साथ समान कहानी। ये एजेंसियों की एजेंसी द्वारा सौंपे जाते हैं और कभी नहीं बदलेंगे।

जब मैंने राज्य कोड के मुद्दे के साथ डीबीए से संपर्क किया और 5 तालिका शामिल हो गई। मुझे जवाब मिलता है कि "हम सामान्यीकृत हैं" और "जुड़ने वाले तेज़ हैं"।

क्या denormalize करने के लिए एक आकर्षक तर्क है? अगर मैं कुछ और नहीं करता तो मैं इसे सैनिटी के लिए करूँगा।

T-SQL में एक ही प्रश्न:

SELECT VehicleAction.VehicleActionID 
     , Agency.AgencyCode AS ActionAgency 
     , VehicleActionType.Description 
     , VehicleDescription.LicensePlateNumber 
     , State.Code AS LPNState 
     , VehicleAction.LatestDateTime AS ActionLatestDateTime 
     , VehicleAction.CreatedDate 
FROM VehicleAction INNER JOIN 
    VehicleActionType ON VehicleAction.VehicleActionTypeId = VehicleActionType.VehicleActionTypeId INNER JOIN 
    ActivityInvolvement ON VehicleAction.VehicleActionId = ActivityInvolvement.VehicleActionId INNER JOIN 
    Agency ON VehicleAction.AgencyId = Agency.AgencyId INNER JOIN 
    VehicleDescription ON ActivityInvolvement.VehicleDescriptionId = VehicleDescription.VehicleDescriptionId INNER JOIN 
    State ON VehicleDescription.LicensePlateStateId = State.StateId 
Where VehicleAction.CreatedDate >= floor(cast(getdate() as float)) 
+0

+1। अच्छा प्रश्न। "स्वच्छता" ध्वनिबाइट के लिए – David

उत्तर

6

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

लेकिन डीजेना सही है कि इस तरह बदलाव करने से पहले आपको वर्तमान और भविष्य की जरूरतों की पूरी समझ की आवश्यकता है। क्या आप सुनिश्चित हैं कि तीन पत्र एजेंसी कोड कभी भी नहीं बदलेंगे, यहां तक ​​कि पांच साल भी? वास्तव में, वास्तव में यकीन है?

+1

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

3

यह पिछले पोस्ट एक आ रही हैं उनका ने वही समस्या के साथ निपटा। उम्मीद है कि यह आपके लिए सहायक होगा।

Dealing with "hypernormalized" data

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

स्वच्छता ... यह अतिरंजित है। विशेष रूप से हमारे पेशे में।

+0

+1। अगर मैं आपको अवसर पर उद्धृत करता हूं तो मन? ;-) – sleske

+0

बिलकुल नहीं। उद्धरण विचारों के विचार के लिए – David

6

कुछ समय पर प्रदर्शन (और सैनिटी) कारणों के लिए कुछ denormalization की आवश्यकता हो सकती है। अपने सभी टेबल/जरूरतों आदि को देखने के बारे में बताना मुश्किल है ...

लेकिन क्यों न केवल कुछ सुविधा दृश्य बनाएं (कुछ जुड़ने के लिए) और फिर सरल प्रश्न लिखने में सक्षम होने के लिए इनका उपयोग करें?

+1

+1 ... उपयोगी, सरल सुझाव। – David

+0

छोटे, सरल, पुन: प्रयोज्य कार्यों का विचार जब भी संभव हो, हम सभी कोड पर लागू होना चाहिए। मुझे टेबल-मूल्यवान कार्यों और इस तरह की चीजों के लिए विचारों से बहुत लाभ मिलता है। और बोनस के रूप में, रिपोर्टिंग भी बहुत आसान हो जाती है। – overslacked

6

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

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

+1

+1 यह इंगित करने के लिए कि डेवलपर्स समय के साथ बढ़ते हैं। मुझे लगता है कि इस स्थिति में, हाइपर-सामान्यीकृत डेटा से निपटना सीखना बेहतर है और डेटा को समायोजित करने के बजाय समायोजित करना बेहतर है। – David

2

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

3

अच्छा, प्रदर्शन के बारे में क्या? यदि प्रदर्शन ठीक है, तो केवल पांच तालिका को एक दृश्य में शामिल करें और, सैनिटी के लिए, डेटा की आवश्यकता होने पर दृश्य से चुनें।

राज्य संक्षेप उन मामलों में से एक हैं जिनमें मुझे लगता है कि सार्थक कुंजी ठीक है। सीमित पंक्तियों के साथ बहुत सरल लुकअप टेबल के लिए और जहां मैं डेटा के पूर्ण नियंत्रण में हूं (जिसका अर्थ है कि यह किसी बाहरी स्रोत से पॉप्युलेट नहीं है) मैं कभी-कभी अर्थपूर्ण चार या पांच वर्ण कुंजी बनाउंगा ताकि कुंजी मान प्रॉक्सी हो कुछ प्रश्नों में पूरी तरह से वर्णनात्मक लुकअप मान के लिए।

3

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

संबंधित मुद्दे