स्कूल उपस्थिति प्रणाली के लिए डेटाबेस डिजाइन

Question

मैं एक ऐसे स्कूल के लिए एक परियोजना पर काम कर रहा हूं जहां एक विशेष मॉड्यूल उपस्थिति प्रणाली से संबंधित है। मैं विकास के लिए लैंप (PHP 5.2+ MYSQL 5+) ढेर का उपयोग कर रहा हूं। अब स्कूल की ताकत लगभग 1500 है और प्रति वर्ष कार्य दिवसों की कुल संख्या लगभग 250 है। इसके अलावा, इसे मिटाए जाने से पहले 5 साल के लिए रिकॉर्ड रखना होगा।

तालिका संरचना

studentId varchar(12) 
date date 
fn varchar(1) *forenoon* 
af varchar(1) *afternoon* 

है मैं बस एक एकल तालिका, एक 5 साल की अवधि के लिए 1,875,000 रिकॉर्ड का मतलब है कि का उपयोग करें। अब इस तरह के एक विशाल डेटाबेस के बजाय, मैंने प्रत्येक वर्ग (खंड नहीं) के लिए एक टेबल बनाने पर विचार किया। इसलिए 12 वर्गों पर विचार करने के बाद, मेरे पास 12 टेबल होंगे, जिसका मतलब प्रति तालिका 1,55,000 रिकॉर्ड औसत है जो प्रबंधनीय है।

क्या यह करने का यह सही तरीका है? या क्या कोई बेहतर तरीका है?

Answer 1

क्या आप कर रहे हैं समय से पहले अनुकूलन कहा जाता है पर गौर करना चाहिए है। यह एक आम गलती है।

आप वास्तविकता के करीब अपनी डेटाबेस संरचना प्राप्त करने के बेहतर हैं और भविष्य में यदि अनुकूलन या गति सुधार की आवश्यकता हो तो आप हमेशा ऐसा कर सकते हैं।

अनुभव से और आपके उदाहरण को देखते हुए एकल तालिका समाधान ठीक दिखता है।

Answer 2

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

मैं इसे 12 कक्षाओं में विभाजित करने के विचार से असहमत हूं, क्योंकि आपको इस बात की कोई गारंटी नहीं है कि यह जिस तरह से रहने जा रहा है (कक्षाएं, कक्षाएं विलय, इत्यादि)।

दक्षता के एक कथित लाभ के लिए अपने डेटाबेस सामान्यीकरण को mucking कुछ आप केवल चरम परिस्थितियों के लिए (कभी तो)

Answer 3

कुछ अंक।

• 2 मिलियन रिकॉर्ड एक बड़ी तालिका नहीं है।
• प्रति वर्ग एक अलग तालिका रखने निश्चित रूप से सामान्य नहीं है।

आपने वास्तव में अन्य तालिका के लिए पर्याप्त जानकारी पुनः लिंक प्रदान नहीं की हैं और यदि कुछ भी हो, तो यह तालिका स्टोर होगी। लेकिन आपको सभी तालिकाओं के लिए 3 एनएफ से शुरू करना चाहिए और यदि आपको प्रदर्शन की समस्याएं मिलती हैं तो केवल तभी बदलना चाहिए।

Answer 4

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

MySQL अब वैकल्पिक सुविधा के रूप में डेटा के विभाजन का भी समर्थन करता है। विभाजन तालिका को विभाजित करने के आपके प्रस्ताव के समान है, लेकिन यह भौतिक स्तर पर किया जाता है, इसलिए यह आपकी स्कीमा का उपयोग कर उपयोगकर्ताओं या डेवलपर्स के लिए दृश्यमान नहीं है। यह एक उपयोगी दृष्टिकोण हो सकता है यदि आपको लगता है कि एकल-तालिका कार्यान्वयन अभी भी बहुत धीमा है। This document MySQL 5.4 में विभाजन का एक सिंहावलोकन प्रदान करता है।

Answer 5

Checksum,

मैं Michiel गूंज opinin है कि इस समय से पहले अनुकूलन है।

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

तो गलत होने के बारे में सोचने के बजाय आगे लिखें कोड पर जाएं!