2013-07-27 4 views
10

मैं अब 2 साल के लिए सिम्फनी का उपयोग कर रहा हूं, अब तक, प्रत्येक प्रोजेक्ट जो मैं बनाता हूं उसे विशेष रूप से प्रत्येक क्लाइंट (यानी एक क्लाइंट, एक कोडबेस, एक डीबी) के लिए तैनात किया जाता है।एसएएएस और सिम्फनी 2 में बहु-किरायेदारी?

आइए कहें कि मेरे पास एक प्रोजेक्ट मैनेजमेंट ऐप है जिसे मैं कई ग्राहकों के लिए तैनात करना चाहता हूं।

  1. धकेल बग फिक्स और उन्नयन: ग्राहकों जाएगा मान लिया जाये कि जो कुछ सुविधाओं मैं प्रणाली में निर्माण के साथ जाना है, अगर मैं प्रत्येक ग्राहक के लिए एक अलग codebase (इसलिए, एक अलग डाटाबेस) की तैनाती, यहाँ समस्याओं मैं पूर्वानुमान हैं दर्दनाक होगा। मुझे इसे हर भंडार में धक्का देना है जिसे मैंने तैनात किया है। यदि मेरे पास उसी ऐप का उपयोग कर 50 ग्राहक हैं तो यह अच्छी तरह से स्केल नहीं करेगा।

  2. प्रबंधन दर्दनाक है। मैं अपने लिए एक व्यवस्थापक प्रणाली कैसे बना सकता हूं जहां मैं सभी परियोजनाओं को एक HTML तालिका में खींच सकता हूं? आखिरकार, प्रत्येक ग्राहक का अपना डेटाबेस होता है, है ना? मेरे लिए मेरे सभी ग्राहकों के सभी रिकॉर्ड के साथ सार्थक कुछ भी करने के लिए, मुझे एक ही समय में अपने सभी डेटाबेस देखने के लिए एक तरीका चाहिए, जो .. मुझे नहीं लगता कि सिम्फनी अनुमति देता है। (मुझे यकीन नहीं है)

  3. उपयोगकर्ता खाता मुद्दे। यदि कोई उपयोगकर्ता एकाधिक कंपनियों के लिए काम करता है, तो वे सभी मेरे प्रोजेक्ट मैनेजमेंट ऐप का उपयोग करते हैं, जिसे उपयोगकर्ता को कई बार साइन अप करना होता है। (मैं अगर मैं OAuth का उपयोग इस धोखा दिया जा सकता है, लेकिन मैं अगर मैं कर सकते हैं वहाँ नहीं जाना कोशिश कर रहा हूँ)

यहाँ समाधान मैं सोचा और कुछ हद तक की कोशिश की है कर रहे हैं।


समाधान 1

एक डेटाबेस और सभी अपने ग्राहकों के लिए एक codebase। परियोजनाएं एक टेबल के नीचे जाएंगी, चालान एक टेबल के नीचे जाते हैं, सभी अपने क्लाइंट_आईडी द्वारा चिह्नित होते हैं। उपयोगकर्ताओं को परियोजनाओं को सौंपा जा सकता है इसलिए कई बार साइन अप करने की आवश्यकता नहीं है।

यह बनाना मुश्किल नहीं है। लेकिन, क्या होता है यदि विभिन्न ग्राहकों को उनके चालान के लिए अलग-अलग कॉलम चाहिए? मेरी चालान तालिका विस्तार जारी रहेगी (अलग-अलग फ़ील्ड जो विभिन्न क्लाइंट चाहते हैं) के साथ, और प्रत्येक पंक्ति में संभावित रूप से कई शून्य फ़ील्ड हो सकते हैं। नहीं उल्लेख करने के लिए, अपने चालान इकाई फ़ाइल आकार में बड़ा हो जाएगा, और मैं डेटाबेस स्कीमा हर बार एक नई अनुकूलन में आता है अद्यतन करने के लिए होगा।


समाधान 2

एक डेटाबेस जहां प्रत्येक ग्राहक अपनी खुद की टेबल उपसर्ग है। तो क्लाइंट ए के लिए, मैं क्लाइंटए_प्रोजेक्ट्स, क्लाइंटए_इनवोइस, क्लाइंटए_ कॉन्फ़िगरेशन इत्यादि का उपयोग कर सकता हूं

यह आदर्श है यदि प्रत्येक ग्राहक अपने फ़ील्ड को कस्टमाइज़ करना चाहता है। लेकिन, क्या इसका मतलब है कि मुझे सिस्टम में आने वाले प्रत्येक नए क्लाइंट के लिए नई इकाई बनाने और कक्षा बनाने की आवश्यकता है? ऐसा लगता है कि इस समाधान के साथ, मुझे प्राप्त होने वाले प्रत्येक नए क्लाइंट के साथ डेटाबेस स्कीमा को अपडेट करने की आवश्यकता है।


वर्तमान में, मैं, स्कीमा-रहित डेटाबेस (मोंगो और सोफे) के साथ प्रयोग कर रहा हूँ उम्मीद है कि अग्रिम तालिका स्कीमा निर्दिष्ट करने के लिए की जरूरत के बिना, मैं परेशानी के बिना समाधान 1 लागू कर सकते हैं। लेकिन मैं अभी भी प्रयोग कर रहा हूं, और इससे पहले कि मैं उत्पादन-तैयार ऐप को तैनात करने की हिम्मत करता हूं, सिम्फनी के साथ मोंगो और सोफे के मुद्दों से अपरिचित होने के पहले।


तो, यह वह जगह है जहां मैं फंस गया हूं। एक स्व-प्रशिक्षित प्रोग्रामर होने के नाते, मुझे लगता है कि मेरे ज्ञान में बहुत सारे छेद हैं जिन्हें भरने की आवश्यकता है (जैसा कि सीएस पृष्ठभूमि से किसी के विपरीत है)। सिम्फनी 2 और बहु-किरायेदारी के बारे में वेब पर कई जगहें नहीं हैं (शायद मैं गलत चीज़ की तलाश में हूं)। यदि कोई मुझे स्पष्ट दिशा में इंगित कर सकता है, शायद सर्वोत्तम प्रथाओं, उदाहरण परियोजनाओं, मैं वास्तव में इसकी सराहना करता हूं!

बीटीडब्ल्यू, मैं इसे सिम्फनी के नवीनतम संस्करण (2.3.2 इस समय) में निष्पादित करने की योजना बना रहा हूं।

अग्रिम लोगों में धन्यवाद।

+0

@ Lu0-dezhang है आपके परिणामों को साझा करने के लिए कोई संभावना है? मैं Symfony3 का उपयोग कर एक नया सास ऐप शुरू कर रहा हूं लेकिन डेटाबेस और सिम्फनी 3 प्रोजेक्ट संगठन के बारे में बिल्कुल भी नहीं सोचा है .... कठिन? – ReynierPM

उत्तर

6

मैं इसी समय के लिए सिम्फनी 2 का उपयोग भी कर रहा हूं (बीईटीए में से एक के बाद से) और मैं आपको समाधान # 1 के साथ जाने की सलाह देता हूं। यदि आप सास जा रहे हैं तो आप ग्राहकों को कोड लिखने के कारणों को कोड नहीं दे सकते हैं (मुख्य रूप से अपडेट/अपग्रेड के साथ समस्याएं)। पूरी परेशानी उपयोगकर्ता प्रबंधन पर होगी - किस उपयोगकर्ता के पास उस डेटा तक पहुंच है, जो समूह, कंपनी और इसी तरह से संबंधित है। यदि अन्यथा ठीक से किया जाता है तो अन्य सभी चीजें उसी उपयोगकर्ता-अज्ञेय तरीके से कोडित की जाएंगी। विभिन्न कंपनियों के लिए अलग-अलग आवश्यकताओं के साथ आपको क्या करना चाहिए? ऐसी विशेषताएं बनाएं configurable। आप विभिन्न स्तरों पर यह लागू कर सकते हैं:

  • सरल इकाई जिम्मेदार बताते हैं: प्रत्येक तालिका में एक attributes क्षेत्र है और JSON, YAML या अन्य गतिशील-structurable सामग्री के रूप में सब कुछ बचाने के लिए,
  • सामान्य विन्यास: एक जगह है जहाँ इकाई है बेस कॉन्फ़िगरेशन संग्रहीत किया जाता है (जिस तरह से मैंने ऊपर लिखा है) और उपयोगकर्ताओं को वहां से नई सुविधाओं का प्रबंधन करने की अनुमति देता है, सभी परिवर्तन सरल इकाइयों,
  • को लागू करते हैं जो मैं Entity Parameters Pattern पर कॉल करता हूं - डिज़ाइन डेटाबेस टेबल जिसमें पैरामीटर प्रकार, पैरामीटर विभिन्न स्तरों पर अन्य इकाइयों के मूल्य और संबंध और फिर सामान्य विन्यास योग्य पैरामीटर बनाते हैं प्रकार जिन्हें पूर्वनिर्धारित अर्थ के साथ किसी भी स्थान पर लागू किया जा सकता है। उदाहरण के लिए "पसंदीदा_सेसन" प्रकार "पसंद_स्ट्रिंग" प्रकार का पैरामीटर होता है जिसमें कॉन्फ़िगरेशन "वसंत, गर्मी, शरद ऋतु, सर्दियों" होता है और जब दिया गया इकाई से जुड़ा होता है तो हमेशा <select> फ़ील्ड को विकल्प के साथ प्रस्तुत करता है और चयनित इकाई को दोनों इकाई और पैरामीटर प्रकार के संबंध में सहेजता है ।

इसके अलावा समाधान # 1 का एक नामुमकिन लाभ है - यह एक कंपनी को और अधिक संभाल सकता है भले ही आप अंत में कोड देना चाहते हैं। आपको बस और जोड़ने की क्षमता को मास्क करने की आवश्यकता होगी। :)

यह प्रश्न Symfony2 टैग किया गया है लेकिन यह वास्तव में नहीं होना चाहिए। इससे कोई फ़र्क नहीं पड़ता कि आप किस फ्रेमवर्क का उपयोग कर रहे हैं, आपको कोड से अपने एप्लिकेशन डिज़ाइन को अमूर्त करना चाहिए और उसके बाद ढांचे को आसानी से काम करने के लिए केवल टूल के रूप में उपयोग करना चाहिए। मैं यह कहना चाहूंगा कि पिछले वाक्य को भी ध्यान में रखना, मैं पूरी तरह से सिम्फनी 2 से प्यार करता हूं। :)

1

मुझे पता है कि यह एक पुराना सवाल है लेकिन दूसरों के लिए उपयोगी हो सकता है।

मैं @ टोमाज़ और समाधान # 1 के साथ सहमत हूं one database - एक डेटाबेस में सभी किरायेदारों। यहां सबसे बड़ी समस्या आगे सुरक्षा मुद्दों को हल करने के लिए उचित डेटाबेस डिज़ाइन है: किरायेदारों के बीच अनधिकृत पहुंच को रोकने के लिए संसाधनों के लिए उपयोग को नियंत्रित किया जाना चाहिए। दूसरी तरफ हमारे पास आसानी से कार्यान्वयन है क्योंकि हम केवल एक डेटाबेस के साथ एकल आवेदन लागू कर रहे हैं।

अच्छा लेख के बारे में Symfony2 और SaaS मॉडल में जाने: http://www.browserlondon.com/blog/2015/01/moving-to-a-saas-model-with-symfony2/

इसके अलावा SaaS मंच में डेटाबेस डिजाइन करने के बारे में लेख "अवश्य पढ़ें" - पैटर्न है कि मंच स्वतंत्र हैं: http://labs.octivi.com/database-design-in-saas-platforms/