उपयोगकर्ता भूमिका निभाने के लिए पसंदीदा डेटाबेस डिजाइन विधि? (हैट बनाम समूह)

Question

मेरे पास मध्यम "आकार" तालिका के साथ मध्यम आकार का MySQL डेटाबेस है जिसमें थिएटर और थियेटर स्कूल से जुड़े हर इंसान के बारे में बुनियादी संपर्क जानकारी है जिसके लिए मैं कई वेब को बनाए रखने और विकसित करने के लिए जिम्मेदार हूं अनुप्रयोगों।

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

संक्षेप में, उनके विभिन्न प्रकार के "टोपी" हैं जो कि किसी भी व्यक्ति को सिस्टम के विभिन्न हिस्सों तक पहुंचने और बातचीत करने के लिए पहनना पड़ सकता है, साथ ही साथ उनके बारे में जानकारी हमारी साइट पर सार्वजनिक पृष्ठों पर उपलब्ध कराई गई।

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

मेरा सवाल यह है कि मॉडल को लागू करने में क्या कमी है? एकमात्र अन्य विकल्प जो मैं सोच सकता हूं वह है कि व्यक्तियों की मेज को उन क्षेत्रों के साथ फुलाएं जो अधिकतर प्रविष्टियों के लिए खाली और बेकार होंगी और फिर "समूह" की एक बोझिल तालिका है जिसके लिए व्यक्ति संबंधित हो सकते हैं, और उसके बाद लगभग हर तालिका के लिए सिस्टम में person_id विदेशी कुंजी है और फिर यह सत्यापित करने के लिए व्यावसायिक तर्क पर निर्भर करता है कि संदर्भित व्यक्ति_आईडी उचित समूह से संबंधित है; लेकिन वह बेवकूफ है, है ना?

कुछ उदाहरण तालिका घोषणाएं नीचे दी गई हैं, जो उम्मीद करनी चाहिए कि मैं वर्तमान में यह सब कैसे एक साथ रख रहा हूं, और उम्मीद है कि मुझे लगता है कि मुझे लगता है कि सिस्टम को विभिन्न स्थितियों की वास्तविकता का मॉडल करने का एक और समझदार तरीका क्यों है से निपटें।

कोई भी और सभी सुझाव और टिप्पणियां आपका स्वागत है। मैं आपके समय की सराहना करता हूं।

संपादित कुछ उत्तरदाताओं सुरक्षा के लिए एसीएल का उपयोग कर उल्लेख किया है - मैं अपने मूल प्रश्न में उल्लेख नहीं था कि मैं विभिन्न प्रणालियों की वास्तविक उपयोगकर्ताओं के लिए सुक्ष्म अभिगम नियंत्रण के लिए एक अलग एसीएल पैकेज का उपयोग वास्तव में कर रहा हूँ। मेरा प्रश्न डेटाबेस स्कीमा में लोगों के बारे में मेटाडेटा संग्रहीत करने के सर्वोत्तम प्रथाओं के बारे में अधिक है।

CREATE TABLE persons (
    `id`   int(11) NOT NULL auto_increment, 
    `firstName`  varchar(50) NOT NULL, 
    `middleName` varchar(50) NOT NULL default '', 
    `lastName`  varchar(75) NOT NULL, 
    `email`   varchar(100) NOT NULL default '', 
    `address`  varchar(255) NOT NULL default '', 
    `address2`  varchar(255) NOT NULL default '', 
    `city`   varchar(75) NOT NULL default '', 
    `state`   varchar(75) NOT NULL default '', 
    `zip`   varchar(10) NOT NULL default '', 
    `country`  varchar(75) NOT NULL default '', 
    `phone`   varchar(30) NOT NULL default '', 
    `phone2`  varchar(30) NOT NULL default '', 
    `notes`   text NOT NULL default '', 
    `birthdate`  date NOT NULL default '0000-00-00', 
    `created`  datetime NOT NULL default '0000-00-00 00:00', 
    `updated`  timestamp NOT NULL, 
    PRIMARY KEY (`id`), 
    KEY `lastName` (`lastName`), 
    KEY `email` (`email`) 
) ENGINE=InnoDB; 

CREATE TABLE teachers (
    `person_id`  int(11) NOT NULL, 
    `bio`   text NOT NULL default '', 
    `image`   varchar(150) NOT NULL default '', 
    `payRate`  float(5,2) NOT NULL, 
    `active`  boolean NOT NULL default 0, 
    PRIMARY KEY (`person_id`), 
    FOREIGN KEY(`person_id`) REFERENCES `persons` (`id`) 
     ON DELETE RESTRICT ON UPDATE CASCADE 
) ENGINE=InnoDB; 

CREATE TABLE classes (
    `id`   int(11) NOT NULL auto_increment, 
    `teacher_id` int(11) default NULL, 
    `classstatus_id` int(11) NOT NULL default 0, 
    `description` text NOT NULL default '', 
    `capacity`  tinyint NOT NULL, 
    PRIMARY KEY(`id`), 
    FOREIGN KEY(`teacher_id`) REFERENCES `teachers` (`id`) 
     ON DELETE RESTRICT ON UPDATE CASCADE, 
    FOREIGN KEY(`classstatus_id`) REFERENCES `classstatuses` (`id`) 
     ON DELETE RESTRICT ON UPDATE CASCADE, 
    KEY (`teacher_id`,`level_id`), 
    KEY (`teacher_id`,`classstatus_id`) 
) ENGINE=InnoDB; 

CREATE TABLE students (
    `person_id`  int(11) NOT NULL, 
    `image`   varchar(150) NOT NULL default '', 
    `note`   varchar(255) NOT NULL default '', 
    PRIMARY KEY (`person_id`), 
    FOREIGN KEY(`person_id`) REFERENCES `persons` (`id`) 
    ON DELETE RESTRICT ON UPDATE CASCADE 
) ENGINE=InnoDB; 

CREATE TABLE enrollment (
    `id`    int(11) NOT NULL auto_increment, 
    `class_id`   int(11) NOT NULL, 
    `student_id`  int(11) NOT NULL, 
    `enrollmenttype_id` int(11) NOT NULL, 
    `created`   datetime NOT NULL default '0000-00-00 00:00', 
    `modified`   timestamp NOT NULL, 
    PRIMARY KEY(`id`), 
    FOREIGN KEY(`class_id`) REFERENCES `classes` (`id`) 
     ON DELETE RESTRICT ON UPDATE CASCADE, 
    FOREIGN KEY(`student_id`) REFERENCES `students` (`id`) 
     ON DELETE RESTRICT ON UPDATE CASCADE, 
    FOREIGN KEY(`enrollmenttype_id`) REFERENCES `enrollmenttypes` (`id`) 
     ON DELETE RESTRICT ON UPDATE CASCADE 
) ENGINE=InnoDB; 

Answer 1

क्या शिक्षक एकमात्र 'व्यक्ति' हैं जो वेतन दर है? आप इसे इस तरह से कर अपने डिजाइन को सीमित कर सकते हैं। आप जो करना चाहते हैं वह एक विशेषता तालिका है जो 'व्यक्ति' के लिए अतिरिक्त विशेषताओं को संग्रहीत करती है। यह भविष्य में संशोधन की अनुमति देगा।

Answer 2

मुझे हैट दृष्टिकोण पसंद है। अतीत में, मैंने टोपी और समूहों का संयोजन लागू किया था। असल में, उपयोगकर्ता द्वारा किए जा सकने वाले सभी संभावित कार्यों (अनुमतियां) की एक सूची होती है। मेरे पास समूह की एक सारणी है। प्रत्येक समूह में 1 या कई क्रियाएं हो सकती हैं (अनुमतियां)। मैं फिर उपयोगकर्ताओं को समूहों को असाइन करता हूं।

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

Answer 3

हां, शिक्षक ही एकमात्र ऐसे व्यक्ति हैं जिनके पास वेतन दर है। उस क्षेत्र को अधिक सटीक रूप से "क्लासपेरेट" कहा जाना चाहिए - यह शिक्षक कर्मचारियों के लिए एक विशेष मामला है। गैर-शिक्षक कर्मचारी हमारे पेरोल सिस्टम में एक अलग लाइन आइटम के रूप में अपने कुल घंटे जमा करते हैं।

Answer 4

मैं शिक्षकों को कर्मचारियों में बदल सकता हूं और कर्मचारी प्रकार जोड़ सकता हूं।

हालांकि किसी भी तरह से आकार या फॉर्म मैं व्यक्तिगत रूप से ईमेल, पता, फोन को व्यक्तिगत तालिका में संग्रहीत नहीं करता। इन सभी के पास अलग-अलग टेबल होना चाहिए क्योंकि लोगों के पास कई ईमेल पते (काम और घर), एकाधिक फोन नंबर (काम, घर, सेल, फ़ैक्स) और एकाधिक पते (कार्य, घर 1, घर 2, विद्यालय इत्यादि) हैं। मैं प्रत्येक को अपनी टेबल में रखूंगा और इसे एक प्रकार असाइन करूंगा ताकि आप पहचान सकें कि किस प्रकार का पता, फोन इत्यादि

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

Answer 5

सुरक्षा के लिए मैं एक्सेस कंट्रोल सूचियों (एसीएल) का उपयोग करना पसंद करता हूं। एसीएल के साथ आपके पास प्रिंसिपल (उपयोगकर्ता या उपयोगकर्ता के समूह) हैं, संसाधन (जैसे फ़ाइल, रिकॉर्ड या रिकॉर्ड का समूह) और क्रियाएं (जैसे पढ़ना, अपडेट करना, हटाना)।

डिफ़ॉल्ट रूप से किसी को भी कोई विशेषाधिकार नहीं है। अनुमति देने के लिए आप फ़ाइल एबीसी तक बॉब पढ़ने के लिए एक प्रविष्टि जोड़ते हैं।

आपको ऐसा कोड ढूंढने में सक्षम होना चाहिए जो आपको इस तरह कुछ लागू करने में मदद करता है। जावा में जेएएएस इस विधि का समर्थन करता है।

Answer 6

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

Answer 7

आपके द्वारा वर्णित समूह और टोपी मॉडल परिवर्तनीय हैं, एक दूसरे के लिए। डेटा हानि के बारे में कोई वास्तविक चिंता नहीं है। विशेष रूप से, "मास्टर समूह" तालिका को "टोपी व्यक्ति" तालिका के बाहरी जोड़ों द्वारा विभिन्न "टोपी विस्तार" तालिकाओं के साथ उत्पादित किया जा सकता है।

यदि आप "टोपी" मॉडल का उपयोग कर रहे हैं तो आपको यह सुनिश्चित करने की ज़रूरत है कि दी गई "टोपी तालिका" उस टोपी की अनूठी विशेषताओं को सटीक रूप से समाहित करे। समूह मॉडल के मुकाबले वहां बहुत कम क्षमा है।

यदि आप इस तरह से जाते हैं तो आप शायद सामान्य कार्यों के लिए कुछ विचार स्थापित करना चाहते हैं - उदाहरण के लिए, यदि कोई "शिक्षक नाम" के लिए किसी फ़ील्ड में टाइप कर रहा है और आप कुछ ऑटोकंपलेट्स को पॉप अप करना चाहते हैं, तो एक दृश्य जो मूल रूप से

SELECT firstName, lastName 
FROM persons 
INNER JOIN teachers ON persons.id = teachers.person_id 

अत्यधिक मदद करेगा।

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

INNER JOIN original_table USING (primary_key) 

में अपने कहां के साथ या equivalencies पर monkeying के बजाय से।

Answer 8

मैं पिछले साल इसी तरह की चीज से गुजर चुका था। सवाल यह था: क्या हम अपनी संस्थाओं को स्पष्ट रूप से या सामान्य रूप से मॉडल करते हैं? आपके उदाहरण में, इसका अर्थ यह होगा कि शिक्षक, छात्र, आदि जैसे संस्थाओं/तालिकाओं के बीच उनके बीच सीधे संबंध हैं या नहीं।

अंत में हम एक सामान्य "पार्टी" मॉडल के लिए गए। पार्टी मॉडल इस प्रकार है:

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

यह एक बेहद शक्तिशाली मॉडल है, जो सीआरएम प्रकार प्रणालियों में काफी आम है। यह मॉडल "The Data Model Resource Book: Volume 1" से काफी अधिक आया, जो ऐसी चीजों के लिए एक उत्कृष्ट संसाधन है।

Answer 9

मैंने पहले पार्टी मॉडल का उपयोग किया था। मैं वास्तव में सबसे कमियों को हल करता हूं।