Mysql
 sql >> डेटाबेस >  >> RDS >> Mysql

मूवी डेटाबेस कैसे डिज़ाइन करें?

आपको विशेषताओं और संस्थाओं के बीच अंतर करना होगा। एक इकाई एक चीज है - आमतौर पर एक संज्ञा। एक विशेषता अधिक जानकारी का वर्णन करने के एक टुकड़े की तरह है। डेटाबेस शब्दजाल में, इकाई =तालिका, विशेषता =फ़ील्ड/कॉलम।

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

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

दूसरी ओर, निर्देशक अलग है। शायद आप निर्देशक का पहला नाम, अंतिम नाम, जन्म तिथि, मृत्यु तिथि (यदि लागू हो), आदि को संग्रहीत करना चाहेंगे। जाहिर है कि आप हर बार जब आप किसी फिल्म में प्रवेश करते हैं तो निर्देशक की जन्म तिथि दर्ज नहीं करना चाहते हैं कि यह व्यक्ति निर्देशन करता है, इसलिए एक निर्देशक के लिए एक अलग इकाई होना समझ में आता है।

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

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

आप वास्तव में इस डिज़ाइन को बहुत दूर तक ले जा सकते हैं, और यह पता लगाने की बात है कि आप इसमें क्या स्टोर करना चाहते हैं।

उदाहरण के लिए, प्रति फिल्म एक निर्देशक होने के बजाय, कुछ फिल्मों में कई निर्देशक होते हैं.. इसलिए फिल्मों और निर्देशकों के बीच कई-से-अनेक संबंध होंगे, इसलिए आपको एक तालिका की आवश्यकता होगी जैसे:

films_directors => **filmid, directorid**

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

films => **filmid**, title, otherstuff...
people => **personid**, name, ....
roles => **roleid**, role name, ....
film_people => **filmid, personid, roleid**
genre => **genreid**, name, ...
film_genre => **genreid, filmid**

आपके पास Film_People तालिका में एक role_details फ़ील्ड भी हो सकता है, जिसमें भूमिका के आधार पर अतिरिक्त जानकारी हो सकती है (उदाहरण के लिए, अभिनेता द्वारा निभाए जा रहे भाग का नाम)।

मैं जॉनर को भी कई<>कई रिश्तों के रूप में दिखा रहा हूं, क्योंकि संभव है कि एक फिल्म कई शैलियों में हो। यदि आप यह नहीं चाहते थे, तो फिल्म_शैली तालिका के बजाय, फिल्मों में केवल एक शैली होगी।

एक बार यह सेट हो जाने के बाद, किसी दिए गए व्यक्ति ने जो कुछ किया है, या एक व्यक्ति ने एक निर्देशक के रूप में क्या किया है, या हर कोई जिसने कभी एक फिल्म का निर्देशन किया है, या एक विशिष्ट फिल्म से जुड़े सभी लोगों के बारे में पूछताछ करना और ढूंढना आसान है। यह आगे और आगे बढ़ सकता है।



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. MySQL डायनेमिक पिवट टेबल

  2. Mysql में विचारों के लिए टिप्पणियाँ बनाएँ

  3. Mysql अल्पविराम से अलग स्ट्रिंग में विशिष्ट शब्द को हटा दें

  4. MySQL में स्ट्रिंग के बाएँ या दाएँ भाग को कैसे लौटाएँ?

  5. MySQL UTF8 को UTF8MB4 समस्याओं और प्रश्नों में माइग्रेट करना