जब लोग "185 डेटाबेस तालिकाएँ" सुनते हैं, तो वे जटिलता को केवल जटिलता के लिए मान लेते हैं। लेकिन हर तालिका इसलिए मौजूद है क्योंकि एक व्यावसायिक आवश्यकता ने उसे माँगा।
यहाँ बताया गया है कि मैंने Nexural स्कीमा कैसे डिज़ाइन किया — वे निर्णय जो काम आए, वे जिन्हें मैं बदलूँगा, और वे पैटर्न जो स्केल करते हैं।
डेटाबेस एक विशाल स्कीमा के रूप में शुरू नहीं हुआ। यह तब बढ़ा जब उत्पाद डोमेन वास्तविक हो गए: उपयोगकर्ता, सब्सक्रिप्शन, ट्रेडिंग वर्कफ़्लो, सामुदायिक सुविधाएँ, एनालिटिक्स, शोध और संचालन।
चरण-आधारित स्कीमा डिज़ाइन
मैंने पहले दिन 185 तालिकाएँ डिज़ाइन नहीं कीं। स्कीमा 7 चरणों में बढ़ा, प्रत्येक ने एक डोमेन जोड़ा:
| चरण | डोमेन | तालिकाएँ | मुख्य निर्णय |
|---|---|---|---|
| 1 | Auth और उपयोगकर्ता | 12 | Supabase Auth + कस्टम प्रोफ़ाइल |
| 2 | सब्सक्रिप्शन | 8 | Stripe वेबहुक-संचालित स्टेट मशीन |
| 3 | ट्रेडिंग | 35 | इंस्ट्रूमेंट, पोज़िशन, सिग्नल, वॉचलिस्ट |
| 4 | समुदाय | 25 | Discord सिंक, मॉडरेशन लॉग, प्रतिष्ठा |
| 5 | एनालिटिक्स | 30 | मीट्रिक्स, रिपोर्ट, टेलीमेट्री इवेंट |
| 6 | शोध | 40 | रणनीतियाँ, संकेतक, बैकटेस्ट परिणाम |
| 7 | संचालन | 35 | अलर्ट, न्यूज़लेटर, ऑडिट लॉग |
प्रत्येक चरण का अपना माइग्रेशन बैच था। मैंने कभी भी किसी नए चरण के विकास के दौरान पिछले चरण की तालिकाओं को संशोधित नहीं किया। इसने डिप्लॉयमेंट को सुरक्षित रखा।
तीन नियम जिनका मैंने पालन किया
नियम 1: हॉट पाथ को छोड़कर सब कुछ नॉर्मलाइज़ करें
कैनोनिकल डेटा हमेशा नॉर्मलाइज़्ड होता है। \
