नहीं, यह संबंध को "एक से शून्य या एक" बनाता है। क्या आपको वास्तव में यही चाहिए?
अगर हां , तो आपका "दूसरा समाधान" बेहतर है:
- यह आसान है,
- कम मेमोरी लेता है (और इसलिए कैशे को "बड़ा" बनाता है)
- बनाए रखने के लिए कम अनुक्रमणिकाएं हैं, जो डेटा हेरफेर को लाभ पहुंचाती हैं,
- और (चूंकि आप InnoDB का उपयोग कर रहे हैं) स्वाभाविक रूप से क्लस्टर डेटा, इसलिए जो उपयोगकर्ता एक-दूसरे के करीब हैं, उनके खाते भी पास-पास संग्रहीत होंगे, जिससे कैशे इलाके और कुछ प्रकार के रेंज स्कैन को लाभ हो सकता है।
BTW, आपको accounts.id . बनाना होगा काम करने के लिए एक साधारण पूर्णांक (स्वतः-वृद्धि नहीं)।
अगर नहीं , नीचे देखें...
खैर, "सर्वश्रेष्ठ" एक अतिभारित शब्द है, लेकिन "मानक" समाधान किसी भी अन्य डेटाबेस के समान होगा:दोनों संस्थाओं (आपके मामले में उपयोगकर्ता और खाता) को एक ही भौतिक तालिका में रखें।
सैद्धांतिक रूप से, आप दो PK के बीच वृत्ताकार FK बना सकते हैं, लेकिन इसके लिए स्थगित की आवश्यकता होगी मुर्गी और अंडे की समस्या को हल करने के लिए बाधाएं, जो दुर्भाग्य से MySQL के तहत समर्थित नहीं हैं।
मेरे पास उस विशेष मॉडलिंग टूल के साथ अधिक व्यावहारिक अनुभव नहीं है, लेकिन मुझे लगता है कि ऐसा इसलिए है क्योंकि यह "एक से कई" है जहां "कई" पक्ष को अद्वितीय बनाकर 1 पर रखा गया था। कृपया याद रखें कि "कई" का अर्थ "1 या कई" नहीं है, इसका अर्थ "0 या कई" है, इसलिए "कैप्ड" संस्करण का अर्थ वास्तव में "0 या 1" है।
न केवल अतिरिक्त फ़ील्ड के लिए संग्रहण व्यय में, बल्कि द्वितीयक अनुक्रमणिका के लिए भी। और चूंकि आप InnoDB का उपयोग कर रहे हैं जो हमेशा क्लस्टर टेबल , सावधान रहें कि द्वितीयक अनुक्रमणिका संकुल तालिकाओं में ढेर-आधारित तालिकाओं की तुलना में कहीं अधिक महंगी हैं।
InnoDB इंडेक्स की आवश्यकता है विदेशी कुंजियों पर।
