कौन सा अधिक कुशल है: एकाधिक MySQL टेबल या एक बड़ी तालिका?

103

मैं अपने MySQL डेटाबेस में विभिन्न उपयोगकर्ता विवरण संग्रहीत करता हूं। मूल रूप से यह विभिन्न तालिकाओं में स्थापित किया गया था, जिसका अर्थ है कि उपयोगकर्ता UserIds के साथ जुड़ा हुआ है और आवश्यक डेटा को प्रदर्शित करने और हेरफेर करने के लिए कभी-कभी जटिल कॉल के माध्यम से आउटपुट करता है। एक नई प्रणाली की स्थापना, यह लगभग सभी तालिकाओं को संबंधित सामग्री की एक बड़ी तालिका में संयोजित करने के लिए समझ में आता है।

क्या यह मदद या बाधा बनने वाला है?
कॉल, अपडेट या खोज / हेरफेर में गति पर विचार?

यहाँ मेरी तालिका संरचना में से कुछ का एक उदाहरण है:

उपयोगकर्ता - उपयोगकर्ता आईडी, उपयोगकर्ता नाम, ईमेल, एन्क्रिप्टेड पासवर्ड, पंजीकरण की तारीख, आईपी
user_details - कुकी डेटा, नाम, पता, संपर्क विवरण, संबद्धता, जनसांख्यिकीय डेटा
user_activity - योगदान, अंतिम ऑनलाइन, अंतिम दर्शन
user_settings - प्रोफ़ाइल प्रदर्शन सेटिंग
user_interests - लक्षित लक्ष्य चर
user_levels - अधिकारों का उपयोग
user_stats - हिट, लंबा

संपादित करें: मैंने अब तक सभी उत्तरों को अपडाउन किया है, उन सभी में ऐसे तत्व हैं जो अनिवार्य रूप से मेरे प्रश्न का उत्तर देते हैं।

अधिकांश तालिकाओं में 1: 1 संबंध होता है जो उन्हें निरूपित करने का मुख्य कारण था।

अगर इन कोशिकाओं के एक बड़े हिस्से के खाली रहने की संभावना है, तो क्या तालिका 100+ कॉलम में फैली हुई है?

mysql database-table

— पीटर क्रेग
स्रोत

यह अन्य प्रश्न भी उपयोगी हो सकता है

— मोस्टी मोस्टैचो

65

निम्न तरीकों / मामलों में एकाधिक तालिकाएँ मदद करती हैं:

(ए) यदि अलग-अलग लोग अलग-अलग तालिकाओं से युक्त अनुप्रयोगों को विकसित करने जा रहे हैं, तो यह उन्हें विभाजित करने के लिए समझ में आता है।

(b) यदि आप डेटा संग्रह के विभिन्न भाग के लिए अलग-अलग लोगों को विभिन्न प्रकार के प्राधिकरण देना चाहते हैं, तो उन्हें विभाजित करना अधिक सुविधाजनक हो सकता है। (बेशक, आप विचारों को परिभाषित करने और उन पर प्राधिकरण देने को उचित रूप से देख सकते हैं)।

(c) डेटा को विभिन्न स्थानों पर ले जाने के लिए, विशेष रूप से विकास के दौरान, यह छोटे फ़ाइल आकारों के परिणामस्वरूप तालिकाओं का उपयोग करने के लिए समझ में आता है।

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

(() यह एक संभावना है: एक मूल्य के डेटा के रूप में आपके द्वारा सोचा गया भविष्य में वास्तव में कई मूल्य हो सकते हैं। उदाहरण के लिए, क्रेडिट सीमा अब तक का एकल मूल्य क्षेत्र है। लेकिन कल, आप मानों को (तारीख से, तारीख, क्रेडिट मूल्य) के रूप में बदलने का फैसला कर सकते हैं। स्प्लिट टेबल अब काम आ सकते हैं।

मेरा वोट कई तालिकाओं के लिए होगा - डेटा के साथ उचित रूप से विभाजित।

सौभाग्य।

— user115905
स्रोत

3

@RohitKhatri: मेरी जानकारी के अनुसार, कई टेबल होने से ज्यादातर मामलों में प्रदर्शन बढ़ेगा।

— हरि हरकर

1

@HariHarker आपके उत्तर के लिए धन्यवाद, लेकिन मुझे लगा कि यह आपके एक्सेस पैटर्न पर निर्भर करता है।

— रोहित खत्री

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

— लिखे

35

तालिकाओं के संयोजन को अपभ्रंश कहा जाता है।

यह JOINएक रखरखाव नरक बनाने की कीमत पर तेजी से चलाने के लिए कुछ प्रश्नों (जो बहुत सारे एस बनाते हैं) बनाने में मदद कर सकता है (या नहीं कर सकता है) ।

MySQLकेवल JOINविधि का उपयोग करने में सक्षम है , अर्थात् NESTED LOOPS।

इसका मतलब यह है कि ड्राइविंग टेबल में प्रत्येक रिकॉर्ड के लिए, MySQLलूप में संचालित तालिका में एक मिलान रिकॉर्ड का पता लगाता है।

रिकॉर्ड का पता लगाना काफी महंगा ऑपरेशन है जो शुद्ध रिकॉर्ड स्कैनिंग के रूप में दर्जनों बार लग सकता है।

अपने सभी रिकॉर्डों को एक तालिका में ले जाने से आपको इस ऑपरेशन से छुटकारा पाने में मदद मिलेगी, लेकिन तालिका अपने आप बड़ी हो जाती है, और तालिका स्कैन में अधिक समय लगता है।

यदि आपके पास अन्य तालिकाओं में बहुत सारे रिकॉर्ड हैं, तो तालिका स्कैन में वृद्धि से रिकॉर्ड के अत्यधिक लाभ को क्रमिक रूप से स्कैन किया जा सकता है।

दूसरी ओर, रखरखाव नरक की गारंटी है।

— Quassnoi
स्रोत

1

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

— रूडी गार्सिया

17

क्या वे सभी 1: 1 रिश्ते हैं? मेरा मतलब है, यदि कोई उपयोगकर्ता, उपयोगकर्ता के अलग-अलग स्तरों के, कह सकता है, या यदि उपयोगकर्ता की रुचियों को उपयोगकर्ता हितों की तालिका में कई रिकॉर्ड के रूप में दर्शाया गया है, तो उन तालिकाओं को विलय करना तुरंत प्रश्न से बाहर हो जाएगा।

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

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

— डेविड हेडलंड
स्रोत

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

— रूडी गार्सिया

यह देखते हुए कि चर्चा विशेष रूप से 1: 1 संबंधों के बारे में है, तालिकाओं को विभाजित करना सामान्यीकरण कार्य नहीं है , है ना? यदि कोई डुप्लिकेट जानकारी नहीं है, तो यह सामान्य होने पर भी इसकी एकल तालिका। (ठीक है, यह 3NFसामान्यीकरण को संतुष्ट नहीं कर सकता है , इसलिए इसे हल करने के लिए दूसरी तालिका से लाभ उठाएं, लेकिन ऐसा प्रतीत नहीं होता है कि ओपी अन्य तालिकाओं को फिर से जारी करने की बात कर रहा है।)

— टूलमेकरसैट

14

क्या उन सभी तालिकाओं का 1-to-1रिश्ता है? उदाहरण के लिए, क्या प्रत्येक उपयोगकर्ता पंक्ति में केवल एक ही पंक्ति होगी user_statsया user_levels? यदि हां, तो उन्हें एक तालिका में संयोजित करने का कोई मतलब हो सकता है। यदि संबंध हालांकि नहीं 1 to 1 है, तो यह संभवत: उन्हें गठबंधन (असामान्य) करने के लिए समझ में नहीं आएगा।

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

ईटीए:

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

यदि आप डेटा का उपयोग करने के तरीके को देखते हैं, तो मेरा अनुमान है कि आप पाएंगे कि आपके 80% प्रश्नों का उपयोग उस डेटा के 20% का उपयोग करता है, शेष 80% डेटा का उपयोग कभी-कभी ही किया जाता है। एक तालिका में अक्सर 20% का उपयोग करें, और 80% का उपयोग करें जिसे आप अक्सर अलग-अलग तालिकाओं में उपयोग नहीं करते हैं और आप शायद एक अच्छा समझौता करेंगे।

— एरिक पेट्रोलेज
स्रोत

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

— पीटर क्रेग

1

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

— रिचर्ड एल।

बहुत दिलचस्प सोचा 80/20 डेटाबेस तालिका डिजाइन को लागू करने के लिए। मुझे ओओपी पर भी सोच रहा था (मैं मुख्य रूप से एक जावा डेवलपर हूं) वर्ग डिजाइन और सोच रहा था कि क्या वही प्रभावी हो सकता है (एक कक्षा में प्राथमिक 80% आवेदन कार्यक्षमता और अन्य कक्षाओं में बाकी)।

— जैक मैकमोबर

1

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

— टूलमेकरसेव

@ टोलमेकरसेव ने अच्छे विचार +1

— ज़ैक

9

एक विशाल तालिका बनाना रिलेशनल डेटाबेस प्रिंसिपलों के खिलाफ जाता है। मैं उन सभी को एक तालिका में शामिल नहीं करूंगा। आपके बार-बार डेटा के कई उदाहरण प्राप्त करने जा रहे हैं। यदि आपके उपयोगकर्ता के तीन उदाहरण हैं, तो आपके पास तीन पंक्तियाँ होंगी, जिसमें तीन अलग-अलग हितों को संग्रहीत करने के लिए एक ही उपयोगकर्ता डेटा होगा। निश्चित रूप से कई 'सामान्यीकृत' तालिका दृष्टिकोण के लिए जाना। डेटाबेस सामान्यीकरण के लिए इस विकी पृष्ठ को देखें ।

संपादित करें: मैंने अपना उत्तर अपडेट किया है, जैसा कि आपने अपना प्रश्न अपडेट किया है ... मैं अपने प्रारंभिक उत्तर से और भी अधिक सहमत हूं ...

इन कोशिकाओं के एक बड़े हिस्से के खाली रहने की संभावना है

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

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

मुझे यह दृष्टिकोण पसंद है, क्योंकि समय में एक पल के स्नैपशॉट के रूप में केवल असमान डेटा अस्थायी रूप से मौजूद है। मुद्दों को सम्मिलित / संशोधित / हटाएं नहीं - बस जब किया जाए तो उसे फेंक दें।

— टूलमेकरसेव

7

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

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

— रूडी गार्सिया
स्रोत

वर्डप्रेस wp_usermetaतालिका ज्यामितीय रूप से बढ़ती है। प्रत्येक उपयोगकर्ता wp_usermetaतालिका में एक्स पंक्तियों को जोड़ता है , मेटा जानकारी के प्रत्येक टुकड़े के लिए एक पंक्ति जिसे हम उस उपयोगकर्ता के लिए रखना चाहते हैं। यदि आप प्रत्येक उपयोगकर्ता के लिए 8 कस्टम फ़ील्ड रखते हैं, तो इसका मतलब है कि wp_usermeta users * 8पंक्तियाँ लंबी होंगी । ऐसा लगता है कि प्रदर्शन के मुद्दे पैदा कर रहे हैं, लेकिन मुझे यकीन नहीं है कि अगर यह मुद्दा है या नहीं ...

— तीसरे

1

मैं देख सकता था कि यदि आपके हजारों उपयोगकर्ताओं के पास यह समस्या हो सकती है। मूल रूप से डेटाबेस को आपकी तलाश के लिए उपयोगकर्ता मेटा टेबल में 10000 * 8 प्रविष्टियों के माध्यम से खोजना होगा। हालाँकि, यदि आप केवल मेटा डेटा को क्वेरी करते हैं, तो मुझे लगता है कि आपका प्रदर्शन बेहतर होगा। यदि आपको हमेशा मेटा डेटा की आवश्यकता होती है, तब भी जब आपको इसकी आवश्यकता नहीं होती है, तो आपके पास समस्याएँ हो सकती हैं। यदि आपको हमेशा मेटा डेटा की आवश्यकता होती है, तो शायद टेबल को विभाजित करना सबसे अच्छा तरीका नहीं है।

— रूडी गार्सिया

1

कल ही हमने एक WP थीम को निपटाया जो सभी उपयोगकर्ताओं को लोड कर रही थी (उपयोग करके get_users()) सिर्फ पेजिंग की गणना करने के लिए। एक बार जब हमने SELECT COUNT(…)पृष्ठांकन के लिए एक क्वेरी का उपयोग करने के लिए कोड को सही किया , तो पृष्ठ लोड समय 28 सेकंड से लगभग 400ms हो गया। मुझे अभी भी आश्चर्य है कि प्रदर्शन में शामिल होने वाली तालिकाओं या एक फ्लैट टेबल की तुलना कैसे की जाती है ... मुझे वेब पर किसी भी प्रदर्शन मैट्रिक्स को खोजने में परेशानी हुई है।

— थर्डेंडर

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

— रुडी गार्सिया

1

मैंने आज ही फिर से इस के माध्यम से पढ़ा और महसूस किया कि 10000 * 8 प्रविष्टियों के बारे में मेरी टिप्पणी सच है, हालांकि जिस तरह से डेटाबेस काम करता है वह इसे ज्यादातर एक गैर मुद्दा बनाना चाहिए। यदि किसी कारण से आप सभी 10000 उपयोगकर्ताओं को हड़प रहे हैं और फिर उनकी मेटा जानकारी भी हास्यास्पद है। मैं किसी भी परिदृश्य के बारे में नहीं सोच सकता जहाँ आप यह चाहते हैं। एक डेटाबेस आसानी से बिजली की गति के साथ एकल उपयोगकर्ता के लिए मेटा पुनर्प्राप्त करेगा, हालांकि विदेशी कुंजी और अनुक्रमण के कारण। मान लें कि आपका db मॉडल सही तरीके से सेट है।

— रूडी गार्सिया

5

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

— Tundey
स्रोत

1

मैं कहूंगा कि यह इस बात पर निर्भर करता है कि अन्य तालिकाओं का वास्तव में क्या मतलब है। क्या एक user_details में 1 और अधिक / उपयोगकर्ता और इतने पर हैं। आपकी आवश्यकताओं के लिए सामान्यीकरण किस स्तर पर सबसे उपयुक्त है, यह आपकी मांगों पर निर्भर करता है।

यदि आपके पास अच्छे सूचकांक के साथ एक तालिका है जो संभवतः तेज होगी। लेकिन दूसरी ओर संभवतः बनाए रखना अधिक कठिन है।

मेरे लिए ऐसा लगता है कि आप User_Details को छोड़ सकते हैं क्योंकि यह उपयोगकर्ताओं के साथ संभवतः 1 से 1 संबंध है। लेकिन बाकी शायद प्रति उपयोगकर्ता पंक्तियों का एक बहुत कुछ है?

— रिचर्ड एल
स्रोत