MySQL डेटाबेस

Question

में ऐतिहासिक डेटा के साथ सर्वोत्तम अभ्यास हाल ही में मैं MySQL डेटाबेस में ऐतिहासिक डेटा संग्रहीत करने के सर्वोत्तम प्रथाओं के बारे में सोचता हूं। अभी के लिए, प्रत्येक संस्करण तालिका में दो कॉलम हैं - valid_from और valid_to, DATETIME प्रकार दोनों। वर्तमान डेटा के साथ रिकॉर्ड्स में valid_from इसके निर्माण दिवस से भरा है। जब मैं इस पंक्ति को अद्यतन करता हूं, तो मैं अद्यतन तिथि के साथ valid_to भरता हूं और valid_from के साथ नया रिकॉर्ड जोड़ता हूं जो पिछले पंक्ति में valid_to जैसा होता है - आसान सामान। लेकिन मुझे पता है कि तालिका बहुत तेज होगी इसलिए डेटा लाने में बहुत धीमा हो सकता है।
मैं जानना चाहता हूं कि आपके पास ऐतिहासिक डेटा संग्रहीत करने के साथ कोई अभ्यास है या नहीं?

Answer 1

"बड़ी" टेबल और प्रदर्शन के बारे में चिंता करने की एक आम गलती है। यदि आप अपने डेटा तक पहुंचने के लिए इंडेक्स का उपयोग कर सकते हैं, तो इससे कोई फर्क नहीं पड़ता कि आपके पास 10000000 रिकॉर्ड हैं - कम से कम ऐसा नहीं है क्योंकि आप मापने में सक्षम होंगे। आपके द्वारा निर्दिष्ट डिजाइन का उपयोग आमतौर पर किया जाता है; यह एक महान डिजाइन है जहां समय व्यापार तर्क का एक प्रमुख हिस्सा है।

उदाहरण के लिए, यदि आप जानना चाहते हैं कि किसी ऑब्जेक्ट की कीमत उस बिंदु पर थी जब ग्राहक ने ऑर्डर दिया था, तो उत्पाद रिकॉर्ड खोजने में सक्षम होने के कारण < order_date मान्य /until या तो शून्य है या> order_date दूर तक है सबसे आसान समाधान।

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

Answer 2

यह पूरा जवाब नहीं है, केवल कुछ सुझाव।

आप is_valid जैसे अनुक्रमित बूलियन फ़ील्ड जोड़ सकते हैं। इसे ऐतिहासिक और वर्तमान रिकॉर्ड के साथ बड़ी तालिका के साथ प्रदर्शन में सुधार करना चाहिए।

सामान्य रूप से - अलग-अलग तालिका में ऐतिहासिक डेटा संग्रहीत करने से आपके आवेदन को जटिल हो सकता है (केवल मिश्रित वर्तमान और ऐतिहासिक रिकॉर्ड के साथ डेटा प्राप्त करने वाले प्रश्न की जटिलता की कल्पना करें ...)।

आज कंप्यूटर वास्तव में तेज़ हैं। मुझे लगता है कि आपको ऐतिहासिक रिकॉर्ड के लिए एकल तालिका और अलग तालिका के साथ प्रदर्शन/परीक्षण करना चाहिए।

इसके अलावा - यह देखने के लिए अपने हार्डवेयर का परीक्षण करने का प्रयास करें कि डेटाबेस को डिज़ाइन करने के तरीके को निर्धारित करने के लिए बड़े टेबल के साथ MySQL कितनी तेज़ है। यदि यह आपके लिए बहुत धीमा है - तो आप MySQL कॉन्फ़िगरेशन को ट्यून कर सकते हैं (बढ़ते कैश/रैम के साथ शुरू करें)।

Answer 3

मैं एक आवेदन पूरा करने के करीब हूं जो वास्तव में ऐसा करता है। मुख्य फ़ील्ड द्वारा मेरे अधिकांश इंडेक्स इंडेक्स पहले और फिर valid_to फ़ील्ड जो मौजूदा रिकॉर्ड के लिए NULL पर सेट है जिससे वर्तमान रिकॉर्ड आसानी से और तुरंत मिल सकते हैं। चूंकि मेरा अधिकांश एप्लिकेशन रीयल टाइम ऑपरेशंस से संबंधित है, इसलिए इंडेक्स तेजी से प्रदर्शन प्रदान करते हैं। एक बार जब किसी को ऐतिहासिक रिकॉर्ड देखने की ज़रूरत होती है, और उस उदाहरण में प्रदर्शन प्रदर्शन होता है, लेकिन परीक्षण से यह बहुत बुरा नहीं होता है क्योंकि अधिकांश रिकॉर्डों में उनके जीवनकाल में बहुत अधिक परिवर्तन नहीं होते हैं।

ऐसे मामलों में जहां आपके पास वर्तमान रिकॉर्ड की तुलना में विभिन्न चाबियों के बहुत अधिक समय समाप्त होने वाले रिकॉर्ड हो सकते हैं, यह से पहले किसी भी प्रमुख फ़ील्ड से वैध_to पर इंडेक्स पर भुगतान कर सकता है।