iKonekt
कन्सोल खोल्नुहोस्

छुट्टाछुट्टै

कोडले होइन, डेटाबेसले पालना गर्ने सीमा

हरेक CRM आफूलाई मल्टी-टेनेन्ट भन्छ। दाबी सस्तो हुन्छ; महत्त्वपूर्ण कुरा कुन तहले सीमा जोगाइरहेको छ भन्ने हो। जवाफ "हाम्रो एप्लिकेशनले सधैं सही फिल्टर थप्छ" भए, त्यो ग्यारेन्टी कहिल्यै क्वेरी लेखेका सबैभन्दा कम आराम गरेका डेभलपर जति मात्रै बलियो हुन्छ।

iKonekt पछि जोडिएको होइन, पहिलो माइग्रेसनदेखि नै मल्टी-टेनेन्ट थियो, जुन गर्वको कुरा जस्तो सुनिन्छ तर वास्तवमा स्वीकारोक्ति हो: पछि यसलाई विश्वसनीय रूपमा जोड्न लगभग असम्भव छ, र प्रयास गर्नेहरू सबैसँग एउटा कथा छ।

पृथक्करण डेटाबेसमा बस्छ। छब्बीस टेबलमध्ये हरेकले आफ्नो टेनेन्ट बोकेको हुन्छ, र यसलाई जाँच्ने नीति हरेक पढाइ र लेखाइमा, एप्लिकेशनभन्दा पूर्ण तल चल्छ। सीमा बिर्सने क्वेरीले अरू कसैका ग्राहक फर्काउँदैन। यसले केही फर्काउँदैन।

पङ्ति-स्तरीय सुरक्षा, बाध्यतात्मक

परिपाटि होइन, कोड समीक्षाको नियम होइन। डेटाबेसले अस्वीकार गर्छ। अठहत्तर नीतिहरू, एक-एक गरेर लेखिएका, उत्पन्न गरिएका होइनन् — किनकि उत्पन्न गरिएको नीति कसैले पढेकै हुँदैन।

मिश्रित कुञ्जीहरू

सन्तान अभिलेखले आफ्नो टेनेन्ट र आफ्नो अभिभावक जोडीका रूपमा एकसाथ संदर्भित गर्छ। गलत कम्पनीको त्रुटिपूर्ण पहिचानकर्ता समाधान हुँदैन — यो सामान्यतया अमान्य सन्दर्भ हो।

कहिल्यै पनि पूर्वनिर्धारित टेनेन्ट हुँदैन

स्कोप बिनाको अनुरोध मौन रूपमा टेनेन्ट शून्यको अनुरोध बन्दैन। यो डेटाबेससम्म पुग्नुअघि नै त्रुटि फाल्छ। बन्द गर्न बिर्सन सकिने कुनै "unscoped" मोड छैन।

आफैं घोषणा गर्न नसक्ने बग

टेनेन्सीको काम हुँदा अधिकांश त्रुटिहरू ठूलो स्वरमा आएका थिए। दुई कम्पनीलाई उही ग्राहक डोमेन दिनुभयो भने डेटाबेस वस्तुहरू तुरुन्तै, त्रुटि कोड र स्ट्याक ट्रेससहित देखिन्थे; दिउँसो खाना अघि नै तपाईंले त्यसलाई मिलाइहाल्नुहुन्थ्यो।

एउटा भने आपत्ति जनाएन। सम्पादनयोग्य प्रम्प्ट ओभरराइडहरूको तालिका प्रम्प्टको किण्ड मात्रमा आधारित थियो — किण्ड र टेनेन्ट दुवैमा होइन। दोस्रो कम्पनीले आफ्नै प्रतिलिपि सम्पादन गर्दा पहिलो कम्पनीको चुपचाप मेटिन्थ्यो — पूर्ण रूपमा वैध SQL मार्फत, कुनै त्रुटि बिना, कुनै चेतावनी बिना, कुनै असफल परीक्षण बिना। यो कुरा एउटा कुञ्जी परिवर्तनपछि बाँकी रहेका प्रत्येक अद्वितीय अनुक्रमणिका एक-एक गरी पढेर भेटियो, यो शंकामा कि ठूलो स्वरमा देखिनेहरूको साथी पनि होलान्।

हामी यो उल्लेख गर्छौं किनभने यही नै यस कामको इमानदार आकार हो। पृथक्करण तपाईंले सुरु गर्ने सुविधा होइन; यो स्किमाका नीरस भागहरू त्यहाँ केही तपाईंसँग असहमत छ भन्ने मान्यतामा पढ्ने बानी हो।

अभिलेखका लागि, परीक्षणहरू: ९४२ वटा, प्रत्येक परिवर्तनमा शून्यबाट पुनर्निर्मित डेटाबेसविरुद्ध चलाइन्छन्। तिनीहरू डिजाइन चतुर छ भनी प्रमाणित गर्न होइनन्। तिनीहरू त्यहाँ छन् किनभने यस विशेष डिजाइनको असफलता मौन हुन्छ, र मौन असफलताहरूलाई कसैले तिनीहरूका पक्षमा कराउनुपर्छ।

पृथक्करणले सामान्य व्यक्तिलाई के दिन्छ

  • एउटा समूह एउटै इन्स्टलबाट धेरै कम्पनी चलाउन सक्छ, र एउटाका विक्रेताले अर्कोको ग्राहक कहिल्यै देख्न सक्दैन — नीतिले होइन, संरचनाले।
  • साझेदार कार्यक्रम, प्रम्प्टहरूको सेट, ग्राहकमाथिको दाबी: सबै प्रति-कम्पनी दायरामा रहन्छन्, त्यसैले एउटा टेनेन्टको कन्फिगरेसन सबैको हुन सक्दैन।
  • मेटाउने अनुरोध साझा थुप्रोभरि होइन, एउटा सीमाभित्रै पूरा गरिन्छ, जसले नै इमानदार उत्तर दिन सम्भव बनाउँछ।
  • र कसैले यसलाई सम्झनु पर्दैन। यही त यसको उद्देश्य हो — सम्झनमा निर्भर ग्यारेन्टी ग्यारेन्टी होइन।

डेटाबेससँग सम्बन्धित नभएको अर्को एक हरफ

परिवारका प्रत्येक सहोदर सेवाले आफ्नै नाम भएको क्रेडेन्सियल राख्छ। कुनै पनि सेवा साझा क्रेडेन्सियलले कुरा गर्दैन, त्यसैले कुनै सेवा अर्कोको रूपमा भूलबश काम गर्न सक्दैन — एक पटक साझा टोकन भएको र त्यो मन पराएको थिएन भन्ने अनुभवबाट सिधै आएको सानो अनुशासन।

यो डेटाबेस नियमसँग उही सोच हो। गलत कुरा निरुत्साहित होइन, असम्भव बनाउनुहोस्, र तपाईंको ध्यान सतर्कतामा होइन, ग्राहकहरूमा खर्चिन्छ।

सीमाएप्लिकेशनभन्दा तल
  • 1२६ तालिकाप्रत्येकले आफ्नो टेनेन्ट बोक्छ, जाँच बाध्यतामा राखेर।
  • 2७२ नीतिहरूछुट्टाछुट्टै लेखिएका, त्यसैले प्रत्येकलाई एक व्यक्तिले पढेको छ।
  • 3९४२ परीक्षणहरूशून्यबाट पुनर्निर्मित डेटाबेसविरुद्ध, प्रत्येक परिवर्तनमा।
  • 4० पूर्वनिर्धारित टेनेन्टहरूदायरा नभएको अनुरोध डेटासम्म कहिल्यै पुग्दैन।

लाइभ बिल्डमा मापन गरिएको

“हाम्रो एप्लिकेशन सधैं कम्पनी अनुसार फिल्टर गर्छ।”

त्यो वाक्यमा “सधैं” शब्दले धेरै भार बोकेको छ।

सीमालाई डेटाबेसभित्र तल सार्नुहोस् र बिर्सिएको WHERE खण्डले अरू कसैका ग्राहक होइन, केही फर्काउँदैन। खाली स्क्रिन असहज परिचयभन्दा राम्रो असफलता हो।

धेरै ब्रान्ड चलाउने समूहहरूका लागि →