आपकी स्कीमा बिल्कुल ठीक दिखती है, आप देख सकते हैं कि अन्य (आज मेरे सहित) कमोबेश पहले समान संरचना के साथ आए थे (एक ही डेटाबेस तालिका में विभिन्न चैट के संदेशों को संग्रहीत करना , एक-से-एक और समूह चैट के लिए डेटाबेस स्कीमा , एक थ्रेडेड प्राइवेट बनाना फेसबुक और जीमेल जैसे मैसेजिंग सिस्टम ) मैं वास्तव में यह नोट करना चाहूंगा कि आपका दृश्य प्रतिनिधित्व सबसे अच्छा है, इसे समझना और अनुसरण करना इतना आसान है :)
सामान्य तौर पर, मुझे लगता है कि "कमरा" ("चैट", "बातचीत") होने से समझ में आता है, भले ही आपके पास इस समय कोई विशिष्ट गुण न हो (जैसा कि यह name हो सकता है , posting_allowed , type (यानी यदि आप न केवल निजी संदेशों और चैट के लिए, बल्कि टिप्पणियों के साथ सार्वजनिक पोस्ट के लिए समान संरचना का पुन:उपयोग करते हैं) और इसी तरह। सिंगल इंडेक्स आईडी के साथ सिंगल टेबल सुपर फास्ट होना चाहिए और शून्य ओवरहेड के करीब होना चाहिए, हालांकि यह सभी मौजूदा कोड को संशोधित करने की आवश्यकता के बिना आसानी से एक्सटेंशन की अनुमति देगा (यानी एक दिन आप एक name जोड़ने का फैसला करते हैं। चैट करने के लिए)। रूम आईडी लॉजिक को participants . के अंदर "छुपा" रखना तालिका पारदर्शी नहीं होगी और न ही कुशल होगी (अर्थात जब आपको चैट की अगली आईडी खोजने की आवश्यकता हो), मैं इसकी अनुशंसा नहीं करूंगा।
