डेटा मॉडलिंग पर मेरी सलाह है:
- आपको वैकल्पिक (अशक्त) कॉलमों का समर्थन करना चाहिए जो 1:1 से अधिक हैं आम तौर पर बोलते हैं . अभी भी ऐसे उदाहरण हैं जहां 1:1 समझ में आता है, आमतौर पर सबटाइपिंग के इर्द-गिर्द घूमता है। जब अशक्त स्तंभों की बात आती है तो लोग अजीब तरह से जुड़ने की तुलना में अधिक व्यंग्यात्मक होते हैं;
- मॉडल न बनाएं भी अप्रत्यक्ष जब तक वास्तव में उचित (नीचे इस पर और अधिक);
- एहसान एकत्रीकरण पर जुड़ता है। यह भिन्न हो सकता है इसलिए इसका परीक्षण करने की आवश्यकता है। देखें Oracle vs MySQL vs SQL Server:Aggregation बनाम शामिल हों इसके उदाहरण के लिए;
- जॉइन N+1 सेलेक्ट से बेहतर हैं। उदाहरण के लिए, एक N+1 चयन डेटाबेस तालिका से किसी ऑर्डर का चयन करना और फिर उस ऑर्डर के लिए सभी लाइन आइटम प्राप्त करने के लिए एक अलग क्वेरी जारी करना है;
- जुड़ने की मापनीयता आमतौर पर है केवल एक मुद्दा जब आप बड़े पैमाने पर चयन कर रहे हों। यदि आप एक पंक्ति का चयन करते हैं और फिर उसमें कुछ चीजों से जुड़ते हैं तो यह शायद ही कभी एक समस्या है (लेकिन कभी-कभी यह होती है);
- विदेशी कुंजी हमेशा होनी चाहिए जब तक आप एक छोटी सी छोटी तालिका के साथ काम नहीं कर रहे हैं तब तक अनुक्रमित रहें;
में अधिक ।
अब जहां तक एक मॉडल की प्रत्यक्षता का सवाल है, मैं आपको एक उदाहरण देता हूं। मान लें कि आप उपयोगकर्ताओं के प्रमाणीकरण और प्राधिकरण के लिए एक प्रणाली तैयार कर रहे हैं। एक अति-इंजीनियर समाधान कुछ इस तरह दिख सकता है:
- उपनाम (आईडी, उपयोगकर्ता नाम, user_id);
- उपयोगकर्ता (आईडी, ...);
- ईमेल (आईडी, user_id, ईमेल पता);
- लॉगिन (आईडी, user_id, ...)
- लॉगिन भूमिकाएं (आईडी, login_id, role_id);
- भूमिका (आईडी, नाम);
- भूमिका विशेषाधिकार (आईडी, role_id, विशेषाधिकार_आईडी);
- विशेषाधिकार (आईडी, नाम)।
तो आपको वास्तविक विशेषाधिकारों में दर्ज उपयोगकर्ता नाम से प्राप्त करने के लिए 6 जुड़ने की आवश्यकता है। निश्चित रूप से इसके लिए एक वास्तविक आवश्यकता हो सकती है, लेकिन अधिक बार इस तरह की प्रणाली को कुछ डेवलपर द्वारा हैंड-राइटिंग के कारण नहीं रखा जाता है, यह सोचकर कि उन्हें किसी दिन इसकी आवश्यकता हो सकती है, भले ही प्रत्येक उपयोगकर्ता के पास केवल एक उपनाम हो, लॉगिन करने वाला उपयोगकर्ता 1 है :1 और इसी तरह। एक आसान उपाय है:
- उपयोगकर्ता (आईडी, उपयोगकर्ता नाम, ईमेल पता, उपयोगकर्ता प्रकार)
और, ठीक है, बस। शायद अगर आपको एक जटिल भूमिका प्रणाली की आवश्यकता है, लेकिन यह भी काफी संभव है कि आप नहीं करते हैं और यदि आप ऐसा करते हैं तो इसमें स्लॉट करना काफी आसान है (उपयोगकर्ता प्रकार उपयोगकर्ता प्रकार या भूमिका तालिका में एक विदेशी कुंजी बन जाता है) या यह आमतौर पर मैप करने के लिए सीधा है पुराना से नया।
यह जटिलता की बात है:इसे जोड़ना आसान है और निकालना कठिन है। आम तौर पर यह अनपेक्षित जटिलता के खिलाफ एक निरंतर सतर्कता है, जो बिना जाने और अनावश्यक जटिलता जोड़कर इसे और भी खराब कर देता है।
