MySQL (या किसी भी डीबी) में लोगों को संग्रहीत करने के लिए - एकाधिक टेबल या सिर्फ एक?

Question

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

मैं ऑब्जेक्ट उन्मुख सोच के साथ ओवरबोर्ड चला गया हो सकता है लेकिन अब मैं एक "व्यक्ति" तालिका बनाने में देख रहा हूं जिसमें सभी लोग शामिल हैं, झंडे/उप-समूह "मॉडल" को विस्तारित करते हैं और जंक्शन पर भूमिका-आधारित विशेषताओं को जोड़ते हैं आवश्यकतानुसार टेबल। अगर हम 250,000 लोगों (MySQL और ISAM पर) कहने के लिए बढ़ते हैं तो यह इतना प्रभावशाली प्रदर्शन करेगा कि भविष्य में डीबीए हमेशा मुझे शाप देंगे? हमारी एकल सबसे आम खोज नाम/उपनाम संयोजन पर है।

उदाहरण के लिए, उदा। सेल्सफोर्स की तरह एक कंपनी, ग्राहक/लीड्स/कर्मचारी सभी केंद्रीय दृश्य तालिका में उप-विचार (बेहतर अवधि की इच्छा के लिए) हैं या वे अलग-अलग तालिकाओं में विभाजित हैं?

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

Answer 1

एक 'व्यक्ति' तालिका सबसे, लचीला, कुशल, और मुसीबत से मुक्त दृष्टिकोण है के लिए एक स्तंभ है।

आपके लिए सीमित खोज करना आसान होगा - उदाहरण के लिए, इस अंतिम नाम वाले सभी लोगों को ढूंढें और ग्राहक कौन हैं। लेकिन आप यह भी पा सकते हैं कि आपको किसी ऐसे व्यक्ति को देखना है जब आप नहीं जानते कि वे क्या हैं - जब आपके पास 'व्यक्ति' तालिका होगी तो यह सबसे आसान होगा।

हालांकि, आपको यह संभावना पर विचार करना चाहिए कि एक व्यक्ति आपके लिए कई चीजें हैं - एक ग्राहक क्योंकि खरीदा गया कुछ और एक ठेकेदार क्योंकि आपने उन्हें नौकरी के लिए किराए पर लिया था। इसलिए, बेहतर होगा, इसलिए, 'जॉइन' टेबल प्राप्त करें जो आपको कई रिश्ते के लिए बहुत कुछ प्रदान करे।

create person_type (
    person_id int unsigned, 
    person_type_id int unsigned, 
    date_started datetime, 
    date_ended datetime, 
    [ ... ] 
) 

(आप निश्चित रूप से, अनुक्रमित और विदेशी कुंजी जोड़ना चाहें, person_id करने के लिए 'व्यक्ति' तालिका एक FK है,। 'Person_type_id' एक FK सभी संभव व्यक्ति प्रकार के लिए अपने संदर्भ तालिका करने के लिए है मैं। हमने दो दिनांक फ़ील्ड जोड़े हैं ताकि आप यह स्थापित कर सकें कि कोई आपके लिए क्या था।)

Answer 2

डेटाबेस के लिए 250,000 रिकॉर्ड बहुत अधिक नहीं है। यदि आप अपनी अनुक्रमणिका को उचित रूप से सेट करते हैं तो आपको इसके साथ कोई समस्या नहीं मिलेगी।

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

यह दृष्टिकोण वास्तव में मुझे

Answer 3

को अच्छा लगता है, उचित विदेशी कुंजी की कमी के साथ, यह महाप्रकार/उप प्रकार पैटर्न का उपयोग करने के लिए बेहतर है। एक Person तालिका (सभी विशेषताओं के लिए आम के साथ) और कई उप प्रकार के टेबल (Employee, Contractor, Customer, आदि), सभी मुख्य व्यक्ति तालिका के साथ 1: 1 संबंध में, और हर प्रकार के व्यक्ति के लिए आवश्यक विवरण के साथ।

चेक एक उदाहरण के लिए @Branko द्वारा इस उत्तर: Many-to-Many but sourced from multiple tables

Answer 4

सैद्धांतिक रूप से यह संभव हो जाएगा कंपनी के लिए काम के लिए एक ग्राहक होने के लिए।

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

हालांकि टॉपनर ने कहा, 250.000 अधिक नहीं है। इसलिए मैं व्यक्तिगत रूप से एक ही व्यक्ति को एक टेबल में स्टोर करने के लिए सुरक्षित महसूस करता हूं।

और फिर प्रत्येक भूमिका (कर्मचारी, ग्राहक, आदि)

Answer 5

भले ही आप एक टेबल समाधान (कोर व्यक्ति विशेषताओं के लिए) के साथ समाप्त हो जाएं, आप इसे विचारों के साथ सारणी बनाना चाहते हैं कुछ बाधाओं पर।

आखिरी चीज जो आप करना चाहते हैं वह उन ग्राहकों को गोपनीय जानकारी भेजती है जिन्हें केवल कर्मचारियों के पास जाना था क्योंकि कोई सही तरीके से शामिल नहीं हुआ था। या एक आकस्मिक क्रॉस जिसमें एक रिपोर्ट पर आय दोगुना हो जाती है (लेकिन केवल उन विशेष ग्राहकों के लिए जो किसी कर्मचारी को किसी तरह से जुड़ा हुआ था)।

यह वास्तव में इस बात पर निर्भर करता है कि आप परतों को कैसे देखना चाहते हैं और कौन से घटक किन परतों और कैसे पहुंच सकते हैं।

इसके अलावा, मुझे लगता है कि आप InnoDB पर MyISAM की अपनी पसंद पर फिर से जाना चाहते हैं।