क्या कोई डेटाबेस है कि आपके पास डेटाबेस में कितनी टेबल हो सकती है? क्या इसे खराब प्रोग्रामिंग या जो कुछ भी माना जाएगा? मेरे पास बहुत सारी उपयोगकर्ता जानकारी है और मैं सोच रहा हूं कि क्या कई टेबल होना ठीक है?क्या कोई डेटाबेस है कि आपके पास डेटाबेस में कितनी टेबल हो सकती है?
यदि आप इस प्रश्न पर विचार कर रहे हैं, तो आपको शायद डेटा को स्टोर करने की योजना बनाने के तरीके को बदलना चाहिए। इसे आम तौर पर डेटाबेस स्कीमा रखने के लिए एक बुरा अभ्यास माना जाता है जहां तालिकाओं की संख्या समय के साथ बढ़ती है। डेटा स्टोर करने का एक बेहतर तरीका कॉलम की पहचान करना है (उपयोगकर्ता आईडी की तरह) और प्रत्येक उपयोगकर्ता के लिए एक पंक्ति का उपयोग करें। आपके पास विभिन्न प्रकार के डेटा के लिए एकाधिक टेबल हो सकते हैं, लेकिन प्रत्येक उपयोगकर्ता के लिए टेबल नहीं होना चाहिए।
यह बुरा क्यों है, महोदय? – bhawin
डेटाबेस सिद्धांत और डिज़ाइन का सर्वोत्तम अभ्यास सर्वोत्तम डेटा के प्रकार के रूप में तालिकाओं के आसपास आधारित होता है, और उस डेटा के उदाहरणों के रूप में पंक्तियां। आप पाएंगे कि अधिकांश पैटर्न, पुस्तकालय और डेटाबेस टूल (एसक्यूएल सहित!) उन धारणाओं के आधार पर आधारित हैं। आम तौर पर, आपको सिस्टम में एक नया प्रकार का डेटा रिकॉर्ड जोड़ने की आवश्यकता होने पर आपको केवल अपनी स्कीमा में एक टेबल जोड़नी चाहिए। – Joshua
आमतौर पर एक तार्किक सीमा संख्या नहीं है। लेकिन यह सवाल चर्चा से पूछता है - आपको लगता है कि आप एक सीमा तक पहुंच सकते हैं? यदि आप कई सारी टेबल तैयार करेंगे, तो ऐसा लगता है कि आप वास्तव में कई पंक्तियां बनाना चाहते हैं ... शायद आप अपने विचार पर विस्तार कर सकते हैं ताकि हम कुछ स्कीमा मार्गदर्शन प्रदान कर सकें ..?
आम तौर पर सीमा, यदि कोई है, तो चिंता करने के लिए पर्याप्त नहीं होना चाहिए। यदि आप खुद को इसके बारे में चिंता करते हैं, तो आपको बड़ी समस्याएं हैं। उदाहरण के लिए यदि आप उन ग्राहकों से निपट रहे थे जिनके पास आदेश हैं, तो आप ग्राहकों के लिए एक टेबल और ऑर्डर के लिए एक टेबल तैयार करेंगे। आपको प्रत्येक ग्राहक के लिए एक टेबल नहीं बनाना चाहिए।
नहीं, mysql में डेटाबेस में तालिकाओं की संख्या की सीमा नहीं है, हालांकि स्पष्ट रूप से आप इस बात से बाध्य होंगे कि आपके पास कितनी डिस्क स्थान उपलब्ध है।
उस ने कहा, यदि आप यह सवाल पूछ रहे हैं, तो आपका संभावित डिजाइन शायद काफी बदसूरत है।
बस इस
http://bobfield.blogspot.com/2006/03/million-tables.html
पाया तो अगर आप संदेह है कि आप दस लाख से अधिक टेबल होगा, आप डेटाबेस की पुनः रचना पर विचार करना चाहिए;) यह भी ध्यान रखें कि इस ब्लॉग पोस्ट 2006
हाँ, एक सीमा है .. लेकिन आपको इसे खोजने की संभावना है। पिछली बार मैंने सुना .. http://forums.mysql.com/read.php?32,100653,100653
मैं एक कारण देख सकता हूं कि कुछ प्रति उपयोगकर्ता एक टेबल चाहते हैं। यदि प्रत्येक उपयोगकर्ता के पास समय के साथ लॉग/प्रविष्टियों/पंक्तियों की बढ़ती संख्या होगी, और आप नहीं चाहते हैं कि कोड केवल विशेष उपयोगकर्ता आईडी से मेल खाने वाली पंक्तियों की तलाश में प्रविष्टियों की विशाल सूची के माध्यम से सॉर्ट करना होगा, तो एप्लिकेशन बस दिए गए उपयोगकर्ता आईडी के साथ एक टेबल की तलाश करें, और तब उस तालिका में सब कुछ केवल उस उपयोगकर्ता के लिए है। जब किसी विशेष उपयोगकर्ता के लिए डेटा की तुलना करना और सॉर्ट करना चाहते हैं तो यह प्रदर्शन में सुधार करेगा। मैंने इस विधि का उपयोग किया है, हालांकि यह एक सौ से भी कम उपयोगकर्ताओं के साथ हो सकता है। हजारों उपयोगकर्ताओं के साथ सामना किए जा रहे किसी भी परिणाम के बारे में सुनिश्चित नहीं है।
उपयोगकर्ताओं को अपनी टेबल में क्यों डाल दिया? मुझे समय की बर्बादी की तरह लग रहा है। पहचानकर्ता आईडी वाला एक उपयोगकर्ता तालिका जो हर बार एक नई पंक्ति जोड़ती है, ठीक काम करेगी।
आईडी "ब्लॉग_Posts" जैसी अन्य तालिकाओं के लिए एक विदेशी कुंजी हो सकती है - प्रत्येक ब्लॉग पोस्ट में एक लेखक होना आवश्यक होगा, और इसलिए आप "AuthorID" कॉलम का उपयोग कर सकते हैं जो आपके उपयोगकर्ता आईडी से संबंधित होगा उपयोगकर्ता टेबल।
स्थान और समय बचाता है - साथ ही यह क्लीनर है।
मुझे यहां कोई समस्या नहीं दिखाई दे रही है। यदि आपके पास "बहुत सारी उपयोगकर्ता जानकारी" है तो मैं बिल्कुल एक तालिका गिनता हूं: "user_information" (या ऐसा कुछ)। – KingCrunch