क्या बेहतर है - कई छोटी टेबल या एक बड़ी टेबल?

Question

मुझे एक डेटाबेस मिला है जो व्यक्तियों के बारे में प्रोफाइल स्टोर करेगा। इन व्यक्तियों के पास लगभग 50 संभव फ़ील्ड हैं।

कुछ सामान्य चीजें हैं, पहला नाम, अंतिम नाम, ईमेल, फोन नंबर।

दूसरों, शौक, कौशल तरह बातें कर रहे हैं दिलचस्पी

कुछ ऊंचाई, वजन, त्वचा का रंग है।

इनमें से प्रत्येक समूह सिस्टम द्वारा अलग-अलग समय पर उपयोग किया जाता है। डेटाबेस के माध्यम से बातचीत करने में सक्षम होने के मामले में मैं लगभग 8 फ़ील्ड में से प्रत्येक में 7 टेबल रखना पसंद करूंगा। करने के लिए सबसे अच्छा अभ्यास क्या है?

संपादित करें: प्रोफ़ाइल मिलान खोजने के लिए डेटा को एक खोज इंजन में उपयोग किया जा रहा है। क्या इससे मैं प्रभावित कर रहा हूं?

Answer 1

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

Answer 2

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

मैं व्यक्तिगत रूप से क्या करूंगा जो आपके डेटा को लॉजिकल इकाइयों में व्यवस्थित करना होगा और उन इकाइयों के आधार पर टेबल बनाना होगा। यह कम से कम है जहां मैं शुरू करूंगा।

Answer 3

कई छोटी सारणी i.e. सामान्यीकरण यहां सबसे अच्छा है। यह flexiblility प्रदान करता है, अनावश्यकता और एक बेहतर डेटाबेस संगठन को कम करता है।

Answer 4

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

Answer 5

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

Answer 6

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

उदाहरण के लिए, क्या आपको परिवर्तनों को ट्रैक करने की आवश्यकता है? यदि जॉन जनवरी 2007 में 5'2 "था और अक्टूबर 2010 में 5'11" है, तो क्या आप जानना चाहते हैं? यदि ऐसा है, तो आपको व्यक्ति को ऊंचाई से दो टेबल में अलग करने की आवश्यकता होगी।

शौक के बारे में कैसे - क्या उन्हें केवल 3 शौक होने की अनुमति है? क्या वे कम/कम हो सकते हैं? क्या आप भविष्य में कुछ पूछना चाहते हैं? यदि ऐसा है, तो आपको एक अलग टेबल की आवश्यकता है।

आपको डेटाबेस डिज़ाइन और सामान्यीकरण पर पढ़ना चाहिए (इस साइट पर कई उत्कृष्ट धागे हैं)।

https://stackoverflow.com/questions/tagged/normalization

Answer 7

जब तक हर व्यक्ति शौक की एक ही नंबर (आईई हर किसी को 2 शौक सूचीबद्ध है) है, यह सामान्यीकृत किया जाना चाहिए।

फ़ील्ड जो व्यक्ति के साथ हमेशा 1 से 1 होती हैं, उसी तालिका में होनी चाहिए। उदाहरण के लिए आयु। किसी भी व्यक्ति के पास दो अलग-अलग उम्र नहीं होगी।

Answer 8

मैं कुछ तालिकाओं की सिफारिश करता हूं। सामान्यीकरण से अधिक प्रबंधन करना मुश्किल होता है और आप जटिल प्रश्नों को लिखना समाप्त कर देंगे जो धीमे प्रदर्शन के साथ समाप्त होता है।

केवल तभी सामान्यीकृत करें जब तार्किक शर्तों में बिल्कुल आवश्यकता हो और सोचें।

तालिका 1:: सीमित जानकारी आप ऊपर दी गई साथ, मैं तीन तालिकाओं के लिए जाना होगा PersonalDetails तालिका 2: क्रियाएँ तालिका 3: विविध

वहाँ तेजी लाने के लिए अन्य तकनीकों हैं क्लस्टरिंग इत्यादि जैसे प्रदर्शन, जिसे आप अपनी ज़रूरत के आधार पर उपयोग कर सकते हैं।

Answer 9

मैं सामान्यीकृत शिविर के साथ हूं। एक प्रक्रिया के साथ प्रत्येक "व्यक्ति" के लिए कुछ मनमाने ढंग से अद्वितीय पहचानकर्ता आवंटित करने के लिए

प्रारंभ:

यहाँ कुछ संकेत आप आरंभ करने के लिए कर रहे हैं। इसे PersonId या ऐसा कुछ कहें। इस पहचानकर्ता को एक सरोगेट कुंजी कहा जाता है। सरोगेट कुंजी का एकमात्र उद्देश्य वास्तविक दुनिया में एक वास्तविक व्यक्ति के बीच 1 से 1 रिश्ते की गारंटी देता है। सरोगेट कुंजी का उपयोग करें जब किसी अन्य विशेषता के मूल्य को में अपने डेटाबेस में "व्यक्ति" में जोड़ दें।

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

प्रत्येक विशेषता को देखें जिसे आप प्रबंधित करना चाहते हैं। निम्नलिखित प्रश्न पूछें: क्या किसी दिए गए व्यक्ति के पास इस विशेषता के लिए केवल एक मान है?

उदाहरण के लिए, प्रत्येक व्यक्ति में बिल्कुल एक "जन्म तिथि" है। लेकिन उनके पास "शौक" कैसे हो सकता है? शायद कई लोगों के लिए शून्य। एकल मूल्यवान गुण (उदाहरण के लिए जन्म तिथि, ऊंचाई, वजन इत्यादि) सामान्य तालिका PersonId के साथ कुंजी के रूप में जाने के लिए उम्मीदवार हैं। प्रत्येक तालिका में विशेषताओं की संख्या इस बिंदु पर चिंता का विषय नहीं होना चाहिए।

हॉबी जैसे बहु मूल्यवान विशेषताओं को थोड़ा अलग उपचार की आवश्यकता है। आप प्रत्येक बहु-मूल्यवान विशेषता के लिए अलग-अलग टेबल बनाना चाहते हैं। उदाहरण के रूप में शौक का उपयोग करके आप निम्न तालिका PersonHobby(PersonId, Hobby) बना सकते हैं। इस तालिका में एक पंक्ति कुछ ऐसा दिखाई दे सकती है: (123, "Stamp Collecting")। इस तरह आप प्रत्येक व्यक्ति के लिए आवश्यक प्रत्येक शौक रिकॉर्ड कर सकते हैं। "ब्याज", "कौशल" आदि के लिए भी ऐसा ही करें

अगर वहाँ काफी बहु मूल्यवान विशेषताओं जहां PersonId + Hobby के संयोजन और कुछ नहीं निर्धारित की एक संख्या (यानी। आप इस "शौक" या "ब्याज" या कर इस व्यक्ति के बारे रिकॉर्ड करने के लिए कुछ भी दिलचस्प नहीं है "कौशल") आप उन्हें में एक विशेषता-मूल्य तालिका में डाल सकते हैं जिसमें संरचना PersonAV(PersonId, AttributeName, Value) जैसी संरचना है। यहां एक पंक्ति दिखाई दे सकती है: (123, "Hobby", "Stamp Collecting")।

आप यह तरीका अपनाते हैं, तो यह भी एक अच्छा विचार एक किराए कुंजी के लिए PersonAV तालिका में AttributeName स्थानापन्न और इसके विवरण को यह कुंजी से संबंधित एक और तालिका बनाने के लिए है। कुछ ऐसा: Attribute(AttributeId, AttributeName)। इस तालिका में एक पंक्ति (1, "Hobby") जैसी कुछ दिखाई देगी और संबंधित PersonAV पंक्ति (123, 1, "Stamp Collecting") हो सकती है। यह आमतौर पर किया जाता है ताकि यदि आपको कभी पता होना चाहिए कि AttributeNames आपके डेटाबेस/एप्लिकेशन में मान्य हैं तो आपके पास उन्हें देखने के लिए एक स्थान है। इस बारे में सोचें कि "ब्याज" AttributeName के लिए मान्य मान है या नहीं - यदि आपने AttributeName वाले किसी व्यक्ति को रिकॉर्ड नहीं किया है तो आपके डेटाबेस पर AttributeName का कोई रिकॉर्ड नहीं है - आप कैसे जानते हैं कि यह मौजूद होना चाहिए या नहीं? अच्छी तरह से इसे Attribute तालिका में देखें!

कुछ विशेषताओं में कई रिश्ते हो सकते हैं और यह भी प्रभावित करेगा कि तालिकाओं को सामान्य कैसे किया जाता है। मैंने को आपके उदाहरण में इनमें से कोई भी निर्भरता नहीं देखा है, इसलिए निम्न पर विचार करें: मान लें कि हमारे पास वेयरहाउस भागों से भरा है, PartIdWeightClass, StockCount और ShipCost निर्धारित करता है। यह एक तालिका कुछ सुझाता है जैसे: Part(PartId, WeightClass, StockCount, ShipCost)। हालांकि अगर गैर-महत्वपूर्ण विशेषताओं के बीच संबंध मौजूद है तो उन्हें बाहर निकाला जाना चाहिए। उदाहरण के लिए मान लें WeightClass सीधे ShipCost निर्धारित करता है। इसका तात्पर्य है कि WeightClass अकेले ShipCost और ShipCost निर्धारित करने के लिए पर्याप्त है Part तालिका से बाहर होना चाहिए।

सामान्यीकरण एक काफी सूक्ष्म कला है। आपको कार्यात्मक निर्भरताओं की पहचान करने की आवश्यकता है जो आपके डेटा मॉडल के सभी विशेषताओं के बीच ठीक से करने के लिए मौजूद है। कार्यात्मक निर्भरताओं के साथ आने वाले विचारों और विचारों का एक उचित विचार लेते हैं - लेकिन यह उचित डेटाबेस डिज़ाइन प्राप्त करने के लिए महत्वपूर्ण है।

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

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