जब भी डेटा डाला जाता है तो 'टेबल' बनाएं और हटाएं क्यों नहीं?

Question

मैंने डीबी स्कीमा के लिए अपने दोस्त के साथ तर्क दिया है।

हमारा ऐप एक प्रकार की सीएसवी फ़ाइल पढ़ता है, और फिर तालिका में डेटा (लगभग 200 पंक्तियां) डालता है। कभी-कभी ऐप को फ़ाइल नाम से डेटा हटाने की आवश्यकता होती है।

तो, मैं सुझाव है folloing तालिका स्कीमा -> [Key], [पाठ], [filename]

यह फ़ाइल नाम के साथ डेटा सम्मिलित करने के लिए, तो फ़ाइल नाम से डेटा को हटाने में सक्षम है (से हटाना [TABLE] जहां फ़ाइल नाम = 'boolaboola')।

लेकिन मेरे दोस्त, वह जोर देता है कि जब भी डेटा डाला जाता है तो "टेबल बनाएं और हटाएं क्यों नहीं?"

उनकी तालिका स्कीमा है -> [Key], [पाठ]

उनका विचार [है अनुप्रयोग एक फ़ाइल को पहचान लेगा, अनुप्रयोग एक तालिका जिसका नाम फ़ाइल नाम है बनाता है। फिर नई तालिका में डेटा डालें। जब हमें फ़ाइल नाम से डेटा हटाने की आवश्यकता है, तो बस तालिका ड्रॉप करें।]

भले ही हमारी तालिका को विदेशी कुंजी की आवश्यकता न हो।

मैं उस विचार से सहमत नहीं हो सका। मेरे अनुभव में, मुझे लगा कि डीबी स्कीमा गलत है ... लेकिन मैं अपने दोस्त को समझा नहीं सकता और समझ नहीं सकता।

कृपया मेरी मदद करें। क्या मैं गलत हूँ? या मैं अपने दोस्त को कैसे राजी कर सकता हूं?

Answer 1

सामान्य रूप से, मैं आपसे सहमत हूं। डेटाबेस स्कीमा को बदलना IMHO आमतौर पर एक दुर्लभ कार्रवाई होना चाहिए, अधिमानतः केवल जब सॉफ्टवेयर अद्यतन किया जाता है। मुझे पता है कि यह बहुत सख्त है और 'un-NoSQL' है, लेकिन यह सब के बाद एक पारंपरिक संबंधपरक डेटाबेस है :)।

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

यदि आप बाद में किसी प्रकार के ओ/आर-मैपर या अन्य टूलींग का उपयोग करना चाहते हैं, तो यह अक्सर आपकी टेबल स्कीमा को स्थिर करने में मदद करता है।

Answer 2

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

Answer 3

बस परिप्रेक्ष्य के लिए, असली दुनिया से एक उदाहरण। वास्तव में एक "उत्तर" नहीं, सिर्फ एक कहानी :) मैंने इसे पोस्ट करने का फैसला किया क्योंकि किसी ने कहा कि स्कीमा बदलना [यानी। बनाने और छोड़ने टेबल] एक दुर्लभ कार्रवाई होना चाहिए। "एक संतोषजनक स्पष्टीकरण देने के बिना।

मैं वर्तमान में एक बहुत बड़ी निगम के लिए एक बड़ी आवेदन पर काम कर रहा हूँ। यह 80% PL/SQL के होते हैं (Oracle) सर्वर साइड और 20% ब्राउज़र जीयूआई (जावास्क्रिप्ट, याहू की उत्कृष्ट वाईयूआई 3 लाइब्रेरी पर आधारित)। जीयूआई में अकेले> 140 व्यक्तिगत मॉड्यूल हैं।

दुर्भाग्यवश दुर्भाग्य से एप्लिकेशन के सर्वर-साइड भाग में कोई मिडलवेयर नहीं है, यह सब लिखा है पीएल/एसक्यूएल में। ऐसा इसलिए है क्योंकि साल पहले यह एक छोटा ऐप था जहां यह आर्किटेक्चर ठीक था, और आपको संस्करण "2 लिखने के लिए कभी भी धन नहीं मिलता है।0 "(जो शून्य से शुरू, दूर 1.0 कोड फेंकने का मतलब है)। (फिर भी, सीमाओं को देखते हुए यह आश्चर्यजनक रूप से अच्छी तरह से लिखा है, भले ही कई PL/SQL कार्यों 1000 लाइनों या इससे भी अधिक अब तक से अधिक)।

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

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

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

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

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

पुनश्च: ओह और वैसे, सिर्फ आम तौर पर कहा जाए तो कोई रास्ता नहीं यहाँ दी परिदृश्य, एक तर्क यह में केवल प्रवेश करना चाहिए अगर यह वास्तव में एक मुद्दा है के रूप में प्रदर्शन के बारे में कहने के लिए बहुत। सभी स्थितियों में से 95% के लिए यह नहीं है, सूची में रखरखाव बहुत अधिक है।

* अलग * फ़ाइलों हर अंत से