उपयोगकर्ताओं और समूहों के साथ एक डेटाबेस बनाने के लिए एक बुनियादी मॉडल क्या है?

Question

मैं एक वेबसाइट के लिए एक बुनियादी सुरक्षा प्रणाली का सबसे अच्छा तरीका खोजने की कोशिश कर रहा हूं। मुझे पता है कि मुझे उपयोगकर्ता और समूह चाहिए।

मुझे लगा कि मेरे पास होगा:

user_table
user_id
user_name
...

group_type
group_id
group_name
parent_id
...

group_table
id
user_id
group_id

पहला एक उपयोगकर्ता है, दूसरा एक समूह है, और तीसरा एक मध्यस्थ तालिका है जो दोनों को जोड़ती है। एक उपयोगकर्ता के कई समूह हैं।

क्या यह ठीक है?

Comments

नाम के अलावा अन्य। आपकी GROUP_TYPEतालिका का नाम GROUPया कुछ समान GROUP_TABLEहोना चाहिए , और उपयोगकर्ता और समूह दोनों को संदर्भित करना चाहिए, क्योंकि यह लिंकिंग है।

— एडम मूस

@adam user_id और group_id के साथ group_table नहीं करता है?

— जॉनी

@AdamMusch इसे ग्रुप नाम नहीं दिया जाना चाहिए, क्योंकि यह एक आरक्षित शब्द है। टेबल्स और कॉलम को कभी भी आरक्षित शब्दों के नाम पर नहीं रखना चाहिए

— फिलो

@ पिल सहमत हो गए। आपके पास एक तालिका SELECTऔर फ़ील्ड का नाम भी हो सकता है FROMताकि आपके पास एक क्वेरी हो जैसेSELECT [FROM] FROM [SELECT]

— JNK

बुनियादी संस्थाओं को 'app_user' और 'app_role' जैसी चीज़ों से बुलाने की कोशिश करें

— ConcernedOfTunbridgeWells

Answer 1

इसे मॉडल करने का पारंपरिक तरीका भूमिका-आधारित सुरक्षा नामक एक पैटर्न का उपयोग करना है ।

यह विचार केवल उपयोगकर्ताओं के समूह का नहीं है, बल्कि अनुमतियों के समूहों का भी है। यहां बताया गया है कि पैटर्न कैसा दिखता है:

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

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

Comments

लेकिन क्या होगा यदि मेरे उपयोगकर्ता की प्रबंधक या जो कुछ भी है और जो किसी कारण से है, उसी उपयोगकर्ता को एक विशेष अनुमति की आवश्यकता है (जो उस भूमिका में नहीं है, और न ही किसी अन्य भूमिका में है)?

— लेवी

@ लेवी - यदि ऐसा होता है तो इसे संभालने का एक तरीका "बॉब की विशेष अनुमतियाँ" की तरह एक विशेष भूमिका बनाना है , जो कि थोड़ा कठिन है, लेकिन यह समस्या को हल करता है जब तक कि आपके पास बहुत अधिक अपवाद न हों इस। यह संभव है कि आपको लगता है कि एक व्यक्तिगत अपवाद वास्तव में एक सूक्ष्म नई भूमिका हो सकती है जिसे आपने नहीं माना है। जब बॉब क्विट करता है तो क्या होता है? क्या बॉब के प्रतिस्थापन को भी उस असाधारण अनुमति की आवश्यकता है? यदि ऐसा है तो आप वास्तव में एक सदस्य के साथ एक भूमिका रखते हैं, अपवाद नहीं।

— जोएल ब्राउन 12

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

— जोएल ब्राउन