क्या डेटाबेस सामान्यीकरण मृत है? [बन्द है]

Question

मुझे पुराने स्कूल में लाया गया है - जहाँ हमने डेटाबेस स्कीमा को डिज़ाइन करने के लिए सीखा है ताकि एप्लिकेशन की व्यावसायिक परत (या बाकी सब चीजों के लिए OOAD का उपयोग कर) कर सकें। मैं डिजाइनिंग स्कीमा (IMHO :) के साथ बहुत अच्छा रहा हूं और अनावश्यक अतिरेक को दूर करने के लिए सामान्यीकृत किया गया है, लेकिन जहां यह गति को प्रभावित नहीं करता है यानी यदि प्रदर्शन एक हिट थे, तो अतिरेक को जगह में छोड़ दिया गया था। लेकिन ज्यादातर ऐसा नहीं था।

रूबी के ActiveRecord या ActiveJDBC जैसे कुछ ORM फ्रेमवर्क के आगमन के साथ (और कुछ अन्य जिन्हें मैं याद नहीं कर सकता, लेकिन मुझे यकीन है कि वहाँ बहुत सारे हैं) ऐसा लगता है कि वे हर मेज के लिए एक सरोगेट कुंजी रखना पसंद करते हैं, भले ही कुछ प्राथमिक विकल्प हों जैसे 'ईमेल' - एकमुश्त 2NF तोड़ना। ठीक है, मैं बहुत ज्यादा नहीं समझता, लेकिन यह मेरी नसों (लगभग) पर हो जाता है जब इनमें से कुछ ORM (या प्रोग्रामर) 1-1 या 1-0 को स्वीकार नहीं करते हैं। 1 (1 से 0 या 1)। वे यह कहते हैं कि यह सब कुछ एक बड़ी मेज के रूप में होना ही बेहतर है, अगर इसमें nulls "आज का सिस्टम इसे संभाल सकता है" की एक टिप्पणी है जो मैंने अधिक बार सुनी है।

मैं इस बात से सहमत हूं कि मेमोरी की बाधाओं का सामान्यीकरण से सीधा संबंध था (अन्य लाभ भी हैं :) लेकिन आज के समय में सस्ती मेमोरी और क्वाड-कोर मशीनों के साथ डीबी सामान्यीकरण की अवधारणा सिर्फ ग्रंथों तक ही रह गई है? DBAs के रूप में आप अभी भी 3NF (यदि BCNF :) नहीं है तो सामान्यीकरण का अभ्यास करते हैं? फर्क पड़ता है क्या? क्या "गंदा स्कीमा" उत्पादन प्रणालियों के लिए अच्छा है? अगर यह अभी भी प्रासंगिक है, तो किसी को कैसे "सामान्यीकरण" के लिए मामला बनाना चाहिए।

( नोट: मैं डेटावेयरहाउस के स्टार / स्नोफ्लेक स्कीमा के बारे में बात नहीं कर रहा हूं, जिनके पास डिजाइन के एक भाग / आवश्यकता के रूप में अतिरेक है लेकिन उदाहरण के लिए StackExchange जैसे बैकएंड डेटाबेस के साथ वाणिज्यिक सिस्टम)

Answer 1

सामान्यीकरण का एक कारण डेटा संशोधन विसंगतियों को दूर करना है
करना है ओआरएम आमतौर पर इसका समर्थन नहीं करते हैं।

मेरे पास हाइबरनेट-डिज़ाइन किए गए डेटाबेस के कई उदाहरण हैं जो इस सिद्धांत को तोड़ते हैं:

• फूला हुआ (लाखों पंक्तियों के 100 से अधिक बार दोहराया गया)
• कोई देखने की मेज (ऊपर देखें)
• नहीं DRI (बाधाएं, कुंजी)
• varchar क्लस्टर किए गए अनुक्रमणिका
• अनावश्यक लिंक टेबल (उदाहरण के लिए 1..0: 1 लागू करते समय एक अशक्त FK कॉलम पर्याप्त होगा)

मैंने जो सबसे बुरा देखा है वह 1TB MySQL डेटाबेस है जो शायद 75-80% इनकी वजह से बहुत बड़ा था

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

ऊपर मेरे उदाहरण में, रिफ्लेक्टर या कुंजियों को बदलने या डेटा को ठीक करने के लिए कोई कर्षण नहीं था: बस डेटाबेस वृद्धि दर और इसके शीर्ष पर एक सार्थक DW बनाने में असमर्थता के बारे में शिकायत करें

Answer 2

ऐसा लगता है कि वे हर मेज के लिए सरोगेट कुंजी रखना पसंद करते हैं, भले ही कुछ में 'ईमेल' जैसी प्राथमिक कुंजी हो - 2NF को एकमुश्त तोड़ना।

सरोगेट कुंजी 2NF नहीं तोड़ते हैं। 2NF कहता है "यदि एक स्तंभ बहु-मूल्यवान कुंजी के केवल एक हिस्से पर निर्भर है, तो उस स्तंभ को एक अलग तालिका में हटा दें।"

वे यह कहते हैं कि एक बड़ी मेज के रूप में सब कुछ होना ही बेहतर है, भले ही इसमें एक टन नल हो

जब तक सामान्यीकरण नियमों का पालन किया जाता है तब तक एक तालिका में कई कॉलम मान्य होते हैं। यदि आप एसक्यूएल और सामान्यीकरण के लाभों को प्राप्त करना चाहते हैं तो विश्लेषण के बिना तालिकाओं को मर्ज करना सही नहीं है।

मैं मानता हूं कि मेमोरी की कमी सामान्यीकरण से सीधा संबंध रखती थी। रिलेशन नॉर्मल फॉर्म एक गणितीय अवधारणा है और इसका मेमोरी से कोई लेना-देना नहीं है।

सामान्यीकरण केवल स्मृति या डिस्क को बचाने के लिए नहीं है, यह अखंडता को जोड़ने के लिए है। आखिरकार यह एक गणितीय अवधारणा है जो हार्डवेयर से स्वतंत्र है।

सरल उदाहरण: कहते हैं कि आप स्कूल की जानकारी को बनाए रखते हैं:

रेस 1: नॉर्थ रिज हाई स्कूल, कैलिफोर्निया, यूएसए

रेस 2: दक्षिण टोरंटो बहादुर हाई स्कूल, ओंटारियो, कनाडा

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

यह एक विसंगति को सामान्य करने वाले संबंधों को रोकने में मदद करता है।

संपादित करें: नीचे टिप्पणी के अनुसार टोरंटो शब्द को ओंटारियो में बदल दिया।

Comments

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— पॉल व्हाइट को फिर से बहाल मोनिका

Answer 3

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

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

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

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

Answer 4

मैं मानता हूं कि स्मृति बाधाओं का सामान्यीकरण से सीधा संबंध था ...

मेमोरी की कमी अभी भी मायने रखती है। मात्रा एक समस्या नहीं है, गति है।

• सीपीयू इस समय कोई तेज़ नहीं हो रहा है (हम अधिक कोर प्राप्त कर रहे हैं, प्रति सेकंड साइकिल नहीं)
• आधुनिक CPU आर्किटेक्चर प्रत्येक प्रोसेसर ( NUMA ) के लिए अलग मेमोरी प्रदान करके गति सीमा को पार करने का प्रयास करता है ।
• मुख्य मेमोरी पर तुलनीय दर पर ऑन-कैश कैश आकार नहीं बढ़ रहा है।
• मेमोरी थ्रूपुट उतना अधिक नहीं है जितना कि अधिकांश लोग उम्मीद करते हैं। क्यूपीआई 25 जीबी / सेकंड के क्षेत्र में है।

इस जमीन में से कुछ को जब INT पर TINYINT का उपयोग करने के लिए कवर किया गया था ? जो आपको उपयोगी लग सकता है। मैं SQLCAT टीम से @ThomasKejser ( ब्लॉग ) की हरकतों का अनुसरण करने का सुझाव भी दूंगा , क्योंकि वे डेटाबेस प्रदर्शन को आगे बढ़ाने के लिए तीव्र गति से हैं। सीपीयू कैश और मेमोरी एक्सेस पैटर्न के प्रभाव और चरम DW स्केल के लिए संबंधपरक मॉडलिंग पर SQLBits प्रस्तुति के हालिया पोस्ट अच्छे उदाहरण हैं।

Answer 5

मेरी राय में, यह अभी भी सामान्य और डी-सामान्य के बीच संतुलन के बारे में है । मैं पूरी तरह से सहमत हूं कि ORM चौखटे केवल चीजों को प्राप्त करने के लिए दृष्टिकोण हैं, लेकिन मुझे नहीं लगता कि यह ऐसी रूपरेखाएं हैं जो डी-सामान्य करते हैं प्रवृत्ति है।

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

अब दिन काफी अलग हैं, भंडारण बहुत सस्ते हैं। तो जाहिर है कि हम पुराने दिनों की तुलना में अधिक अतिरेक को सहन कर सकते हैं, यह भी दिखाई देने वाला BIG_TABLE दृष्टिकोण है। अधिक समय दक्षता प्राप्त करने के लिए, अंतरिक्ष दक्षता का त्याग करना होगा।

लेकिन, बिग-टेबल दृष्टिकोण कहानी का अंत नहीं है, यह अभी भी समय और स्थान के बीच का संतुलन है, पीबी वॉल्यूम डेटा को प्रबंधित करने के मामले में, कुछ डेवलपर ने शेष राशि को अंतरिक्ष दक्षता में वापस लेना भी शुरू कर दिया है, यही कारण है कि संरचनाओं जैसे BIG-TABLE में कुछ डेटा को सामान्य करने के लिए काम किया जाता है।

एक शब्द में, सामान्यीकरण दृष्टिकोण निश्चित रूप से मृत नहीं है, लेकिन पुराने दिनों की तुलना में यह निश्चित रूप से अनदेखी है।

Answer 6

CJ Date आपके प्रश्न का उत्तर यहां देती है - सामान्यीकरण (प्रारंभिक) वीडियो मुफ्त है।

http://shop.oreilly.com/product/0636920025900.do

संक्षिप्त उत्तर: सामान्यीकरण चीजों को करने का गणितीय रूप से सही तरीका है। यदि आप ठीक से सामान्य नहीं करते हैं, तो आपका डेटा मॉडल बस गलत है।