आपको संभवतः कुछ शब्दावली कुछ गलत होने के लिए यहां मेरे साथ सहन करना होगा क्योंकि मुझे यह भी पता नहीं था कि यह पूरे 'बहु-किरायेदार' सॉफ्टवेयर में सेवा श्रेणी के रूप में गिर गया है, लेकिन यहां यह करता है ।बहु-किरायेदार PHP सास - प्रत्येक ग्राहक के लिए अलग डीबी, या उन्हें समूह?
मैंने क्लाइंट के लिए सदस्यता प्रणाली (PHP में) विकसित की है। अब हम इसे अपने अन्य ग्राहकों के लिए पूरी तरह से होस्ट किए गए समाधान के रूप में पेश कर रहे हैं, जो सबडोमेन (या यहां तक कि अपना स्वयं का डोमेन) प्रदान करते हैं।
विकल्प मैं मेज पर है, जहाँ तक डेटा भंडारण चला जाता है लग रहे हैं:
विकल्प 1 - स्टोर सब कुछ 1 बड़ा डेटाबेस में, और टेबल की जरूरत है कि एक 'CLIENT_ID' क्षेत्र है यह (लगभग 30 टेबल होंगे जो इसे लागू होंगे), और उनके पास मानचित्र बनाने के लिए उनकी मुख्य सेटिंग्स, विवरण, आदि और डोमेन को संग्रहीत करने वाले 'क्लाइंट' टेबल हैं। यह तब एक वैश्विक रूप से सुलभ चर सेट करता है जिसमें उनकी व्यक्तिगत क्लाइंट आईडी होती है - मुझे स्पष्ट रूप से क्लाइंट_आईडी कॉलम की जांच करने के लिए प्रत्येक क्वेरी को संशोधित करना होगा।
विकल्प 2 - 'साझा संदर्भ' तालिकाओं और 'क्लाइंट' तालिका के साथ एक मास्टर टेबल है। फिर अन्य डेटाबेस के 'ब्लॉक' हैं, जिनमें से प्रत्येक में 10 क्लाइंट हैं। क्लाइंट को अपनी क्लाइंट आईडी के साथ प्रीफ़िक्स्ड, अपनी डेटाबेस टेबल मिल जाएगी। यदि कुछ वास्तव में गलत हुआ तो यह अन्य क्लाइंट डेटा देखने से बचाने के लिए सुरक्षा की थोड़ी सी सुरक्षा जोड़ता है।
विकल्प 3 - विकल्प 2 के रूप में वास्तव में एक ही है, सिवाय इसके कि आप 1 प्रत्येक और हर ग्राहक के लिए डेटाबेस है, पूरी तरह से अन्य क्लाइंट से उन्हें अलग करने, और सैद्धांतिक रूप से थोड़ा अधिक सुरक्षा प्रदान करने कि अगर 1 ग्राहक की टेबल को हैक कर लिया है या नहीं तो कर रहे थे क्षतिग्रस्त, यह किसी और को प्रभावित नहीं करेगा। सबसे बड़ा नकारात्मक पक्ष यह है कि जब एक नए ग्राहक को तैनात करते हैं, तो एक संपूर्ण डेटाबेस, उपयोगकर्ता और पासवर्ड को स्थापित करने की आवश्यकता होती है, आदि। क्या यह संभवतया उचित मात्रा में ओवरहेड का कारण बन सकता है, या यह उतना ही होगा जितना कि आपके पास सभी में एक था डेटाबेस?
कुछ बिंदुओं के साथ-साथ इन ग्राहकों में से कुछ ग्राहकों के लिए सभी विवरणों के साथ 5000+ 'ग्राहक' होंगे - यही कारण है कि विकल्प 1 एक मुद्दा हो सकता है - अगर मेरे पास 100 ग्राहक हैं , जो 1 टेबल में आधे मिलियन पंक्तियों के बराबर हो सकता है।
क्या मैं सोचने में सही हूं विकल्प 3 स्थिति ऐसी स्थिति में जाने का सबसे अच्छा तरीका होगा जहां ग्राहक डेटा की सुरक्षा (और भुगतान जानकारी) महत्वपूर्ण है। मेरे पास सिफारिशों से, कुछ लोगों ने विकल्प 1 के साथ जाने के लिए कहा है क्योंकि 'यह आसान है' हालांकि मैं वास्तव में इसे इस तरह से नहीं देखता हूं। मैं इसे लाइन के नीचे एक संभावित बाधा के रूप में देखता हूं, निश्चित रूप से यदि मैं अपना स्वयं का डेटाबेस रखता हूं तो निश्चित रूप से मैं ग्राहकों को अधिक आसान स्थानांतरित कर सकता हूं।
धन्यवाद ओजी - यह मेरी सोच भी थी। एकमात्र संभावित दोष, हालांकि यह एक प्रमुख नहीं है, सभी डेटाबेस में टेबल अपडेट को दबा रहा है। हालांकि, चूंकि सभी डीबी तालिका के समान सेट को उसी समान संरचना के साथ चलाएंगे, सैद्धांतिक रूप से मैंने सोचा होगा कि सभी डीबी विवरणों के माध्यम से लूप करने के लिए एक सरल स्क्रिप्ट बनाई जा सकती है, कनेक्ट करें, अद्यतन क्वेरी चलाएं, फिर डिस्कनेक्ट करें अगला डीबी। – Sk446