आप कस्टम फ़ील्ड के साथ उपयोगकर्ता डेटाबेस कैसे डिज़ाइन करेंगे

Question

यह सवाल है कि मुझे एक डेटाबेस को कैसे डिज़ाइन करना चाहिए, यह रिलेशनल / नॉस्कल डेटाबेस हो सकता है, जो बेहतर समाधान होगा

---

एक आवश्यकता को देखते हुए आपको एक ऐसी प्रणाली बनाने की आवश्यकता होगी जिसमें "कंपनी" और "उपयोगकर्ता" को ट्रैक करने के लिए एक डेटाबेस शामिल होगा। एक एकल उपयोगकर्ता हमेशा केवल एक कंपनी से संबंधित होता है

• एक उपयोगकर्ता केवल एक कंपनी से संबंधित हो सकता है
• एक कंपनी में कई उपयोगकर्ता हो सकते हैं

"कंपनी" तालिका के लिए डिज़ाइन काफी सीधा है। कंपनी के निम्नलिखित गुण / कॉलम होंगे: (इसे सरल रखें)

ID, COMPANY_NAME, CREATED_ON

पहला परिदृश्य

सरल और सीधे आगे, सभी उपयोगकर्ताओं के पास एक ही विशेषता है, इसलिए यह आसानी से संबंधपरक शैली, उपयोगकर्ता तालिका में किया जा सकता है:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON

दूसरा परिदृश्य

यदि विभिन्न कंपनियां अपने उपयोगकर्ता के लिए अलग प्रोफ़ाइल विशेषता संग्रहीत करना चाहती हैं तो क्या होगा। प्रत्येक कंपनी में विशेषताओं का एक निर्धारित समूह होगा जो उस कंपनी के सभी उपयोगकर्ताओं पर लागू होगा।

उदाहरण के लिए:

• कंपनी A स्टोर करना चाहती है: LIKE_MOVIE (बूलियन), LIKE_MUSIC (बूलियन)
• कंपनी B स्टोर करना चाहती है: FAV_CUISINE (स्ट्रिंग)
• कंपनी C स्टोर करना चाहती है: OWN_DOG (बूलियन), DOG_COUNT (int)

दृष्टिकोण १

जानवर बल तरीका उपयोगकर्ता के लिए एक एकल स्कीमा है और जब कंपनी से संबंधित न हों तो उन्हें नल दें।

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, LIKE_MOVIE, LIKE_MUSIC, FAV_CUISINE, OWN_DOG, DOG_COUNT, CREATED_ON

जो थोड़े बुरा है क्योंकि आप बहुत से NULLS और उपयोगकर्ता पंक्तियों के साथ समाप्त हो जाएंगे, जिनमें ऐसे स्तंभ हैं जो उनके लिए अप्रासंगिक हैं (यानी कंपनी A से संबंधित सभी उपयोगकर्ताओं के पास FAV_CUISINE, OWN_DOG, DOG_COUNT के लिए NULL मान हैं)

दृष्टिकोण २

एक दूसरा तरीका है, "फ्री फॉर्म फील्ड":

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_1, CUSTOM_2, CUSTOM_3, CREATED_ON

जो अपने आप में गंदा होगा क्योंकि आपको पता नहीं है कि कस्टम फ़ील्ड क्या हैं, डेटा प्रकार संग्रहीत मूल्यों के परावर्तक नहीं होगा (उदाहरण के लिए हम VARCHAR के रूप में इंट्यू वैल्यू स्टोर करेंगे)।

दृष्टिकोण ३

मैंने PostgreSQL JSON फ़ील्ड में देखा है, जिस स्थिति में आपके पास होगा:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_PROFILE_JSON, CREATED_ON

इस स्थिति में, आप किसी उपयोगकर्ता के लिए अलग स्कीमा कैसे लागू कर पाएंगे? कंपनी A के उपयोगकर्ता के पास ऐसा स्कीमा होगा जो दिखता है

 {"LIKE_MOVIE":"boolean", "LIKE_MUSIC": "boolean"}

जबकि कंपनी C के साथ एक उपयोगकर्ता के पास एक अलग स्कीमा होगा:

 {"OWN_DOG ":"boolean", "DOG_COUNT": "int"}

---

मुझे इस मुद्दे को कैसे हल करना चाहिए? मैं इस लचीली स्कीमा के लिए एक एकल "ऑब्जेक्ट" (उपयोगकर्ता) के लिए अनुमति देने के लिए डेटाबेस को ठीक से कैसे डिज़ाइन कर सकता हूं जो उनके (कंपनी) संबंधों के आधार पर है?

संबंधपरक समाधान? nosql समाधान?

---

संपादित करें: मैंने "CUSTOM_PROFILE" तालिका के बारे में भी सोचा है जो अनिवार्य रूप से कॉलम के बजाय पंक्तियों में उपयोगकर्ता विशेषताओं को संग्रहीत करेगा।

इस दृष्टिकोण के साथ 2 समस्याएं हैं:

1) डेटा कॉलम के बजाय पंक्तियों के रूप में प्रति उपयोगकर्ता बढ़ता है - और इसका मतलब है कि उपयोगकर्ता की पूरी तस्वीर प्राप्त करने के लिए, बहुत सारे जुड़ने की आवश्यकता होती है, कई अलग-अलग कस्टम विशेषताओं पर "कस्टम प्रोफ़ाइल" तालिका में शामिल होते हैं।

2) डेटा मूल्य हमेशा सामान्य होने के लिए VARCHAR के रूप में संग्रहीत किया जाता है, भले ही हमें पता हो कि डेटा को पूर्णांक या बूलियन आदि माना जाता है।

Comments

यदि अलग-अलग कंपनियों के प्रत्येक ग्राहक पर अलग-अलग, बहु-मूल्यवान डेटा सेट हैं, तो आपको बिल्कुल एक Company_CUSTOMER लिंकिंग टेबल की आवश्यकता है। बाकी सब चीज़ों से आपको बहुत जल्द दर्द होगा।

— ३

कस्टम डेटा के साथ लिंकिंग टेबल कैसे मदद करेगी? कॉलम अभी भी अलग

— noobcser

आपको "कंपनी: IKEA, ग्राहक: Kilian, ATTRIBUTE: पासवर्ड, VALUE: बिल्ली का बच्चा" जैसे एक टपल के साथ "किलियन का पासवर्ड" बिल्ली का बच्चा है "इस तथ्य का प्रतिनिधित्व करना चाहिए। कुछ भी सरल काम नहीं करेगा।

— किलिअन फोथ

एक स्कीमा एक निश्चित चीज़ है, परिभाषा द्वारा; यदि आप नहीं जानते कि आप उन क्षेत्रों को स्थापित नहीं कर सकते हैं जिनकी आपको आवश्यकता है। इस तरह की समस्याओं के लिए एंटिटी-एट्रीब्यूट-वैल्यू पर एक नज़र डालें, जैसे कि रिलेशनल डेटाबेस में हल किया जाता है।

— मेसन व्हीलर

Answer 1

कृपया इसे एक विकल्प के रूप में मानें। पिछले दो उदाहरणों में दोनों की आवश्यकता होगी कि आप स्कीमा में बदलाव करें क्योंकि एप्लिकेशन का दायरा बढ़ता है इसके अलावा "custom_column" समाधान का विस्तार करना और बनाए रखना मुश्किल है। आखिरकार आप Custom_510 के साथ समाप्त हो जाएंगे और फिर कल्पना करें कि इस तालिका के साथ काम करना कितना भयानक होगा।

पहले अपनी कंपनियों स्कीमा का उपयोग करते हैं।

[Companies] ComnpanyId, COMPANY_NAME, CREATED_ON

आगे हम आपके उपयोगकर्ता स्कीमा का उपयोग शीर्ष स्तर की आवश्यक विशेषताओं के लिए भी करेंगे जो सभी कंपनियों द्वारा उपयोग / साझा की जाएंगी।

[Users] UserId, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON

आगे हम एक तालिका का निर्माण करते हैं जहाँ हम अपनी गतिशील विशेषताओं को परिभाषित करेंगे जो प्रत्येक कंपनियों के लिए विशिष्ट होती हैं कस्टम उपयोगकर्ता विशेषताएँ। तो यहां एट्रीब्यूट कॉलम का एक उदाहरण मूल्य "लाइकम्यूजिक" होगा:

[UserAttributeDefinition] UserAttributeDefinitionId, CompanyId, Attribute

आगे हम एक UserAttributes तालिका को परिभाषित करते हैं जो उपयोगकर्ता विशेषता मानों को धारण करेगी

[UserAttributes] UserAttributeDefinitionId, UserId, Value

प्रदर्शन के लिए बेहतर होने के लिए इसे कई तरीकों से संशोधित किया जा सकता है। आप UserAttributes के लिए कई तालिकाओं का उपयोग कर सकते हैं, जो हर एक डेटा प्रकार को विशिष्ट मान में संग्रहीत किया जा रहा है या बस इसे VarChar के रूप में छोड़ दें और इसके साथ कीवल्यू स्टोर की तरह काम करें।

आप UserAttributeDefiniton तालिका से CompanyId को स्थानांतरित करना चाहते हैं और भविष्य में प्रूफिंग के लिए एक क्रॉस रेफरेंस टेबल भी बना सकते हैं।

Comments

धन्यवाद - मैं हालांकि इस तरह के दृष्टिकोण के बारे में - कृपया संपादन देखें। 2 समस्याएं: 1) डेटा पंक्तियों के रूप में बढ़ता है, जिसका अर्थ है कि उपयोगकर्ता की पूरी तस्वीर प्राप्त करने के लिए, आपको बहुत सारे जुड़ने होंगे। 2) "मूल्य" हमेशा सामान्य होने के लिए VARCHAR के रूप में संग्रहीत किया जाएगा, भले ही मूल्य वास्तव में इंट या बूलियन आदि हो

— noobcser

यदि आप टेबल आइडेंटिटी के लिए int / bigint का उपयोग करते हैं और उन पर शामिल नहीं होते हैं जो आपके पास कोई प्रदर्शन समस्याएँ हैं जब तक कि आप अत्यधिक संख्या में पंक्तियों में न हों। अब यदि आप विशेषता मानों के आधार पर खोजना शुरू करते हैं तो यह एक बड़ी समस्या हो सकती है यदि आप बड़ी संख्या में रिकॉर्ड प्राप्त करना शुरू करते हैं। इस मामले में, मैं यह निर्धारित करने के लिए एक डीबीए के साथ काम करूंगा कि क्या ऐसे सूचकांक हैं जो बनाए जा सकते हैं या शायद एक अनुक्रमित दृश्य है जो इस प्रकार की खोजों को गति दे सकता है। मैंने एक समान स्कीमा का उपयोग किया है और यह 100 मिलियन रिकॉर्ड्स में एक वर्ष में कोई प्रदर्शन नहीं करता है, इसलिए जब भी बेस डिजाइन बहुत अच्छी तरह से काम करता है IMO

— पी। रो।

यदि रिपोर्टिंग, फ़िल्टरिंग, क्वेरी की आवश्यकता है और विभिन्न विशेषताओं अलग डेटा सेट के हो सकते हैं। क्या यह दृष्टिकोण NoSQL से बेहतर होगा? मैं प्रदर्शन अंतर को समझने की कोशिश कर रहा हूं। ऐसी ही स्थिति केवल उपयोगकर्ता उन रिपोर्टों को परिभाषित कर सकती है जिनमें उपयोगकर्ता परिभाषित फ़ील्ड हैं।

— कोस

उपरोक्त दृष्टिकोण में, हम खोज चीज़ को कैसे लागू करते हैं, अलग-अलग। कंपनियां उपयोगकर्ताओं के क्षेत्रों सहित अपने क्षेत्रों पर भी खोज करना चाहती हैं। इसके शीर्ष पर स्केलेबल खोज प्रदान करने के लिए सही तरीका क्या है

— techagrammer

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

— पी। रोए

Answer 2

NoSQL डेटाबेस का उपयोग करें। कंपनी और उपयोगकर्ता दस्तावेज होंगे। उपयोगकर्ताओं को उनके स्कीमा का हिस्सा गतिशील रूप से उपयोगकर्ता टेम्पलेट (उस कंपनी के लिए फ़ील्ड / प्रकार को इंगित करने के लिए पाठ) के आधार पर बनाया जाएगा।

\Company\<uniqueidentifier>
    - Name: <Name>
    - CreatedOn: <datetime>
    - UserTemplate: <Text>

\User\<uniqueidentifier>
    - COMPANY_ID: <ID>
    - FIRST_NAME: <Text>
    - LAST_NAME: <Text>
    - EMAIL: <Text>
    - CREATED_ON: <datetime>
    - * Dynamically created fields per company

यह है कि यह Firebase.com की तरह कुछ में कैसे लग सकता है । आपको यह सीखना होगा कि आप जो भी चुनते हैं, उसमें यह कैसे करना है।

Comments

यह मैं या JSON कॉलम के बारे में सोच रहा हूं। PRoe द्वारा प्रस्तावित समाधान की तुलना में रिपोर्टिंग को फ़िल्टर करने, रिपोर्टिंग को कैसे फ़िल्टर किया जाता है।

— कोस

जब भी आप डेटा को json या xml में कंप्रेस करते हैं और फिर इसे एक कॉलम में टॉस करते हैं, तो यह खोज पर बहुत धीमा हो जाएगा। यदि आपको मेरे उत्तर में प्रस्तुत डेटा को खोजने की आवश्यकता है तो मैं डेटा को पुनः प्राप्त करने के लिए अनुक्रमित दृश्यों का उपयोग करने की सलाह दूंगा। यदि वह समाधान आदर्श नहीं है, तो मैं डेटा को एक संरचना में कॉपी करने के लिए ईटीएल का उपयोग करने की सलाह दूंगा जिसे आसानी से खोजा जा सकता है और उस पर सूचना दी जा सकती है।

— पी। रो

उपरोक्त दृष्टिकोण में, हम खोज चीज़ को कैसे लागू करते हैं, अलग-अलग। कंपनियां उपयोगकर्ताओं के क्षेत्रों सहित अपने क्षेत्रों पर भी खोज करना चाहती हैं। इसके शीर्ष पर स्केलेबल खोज प्रदान करने के लिए सही तरीका क्या है

— techagrammer

नोसक्ल डेटाबेस में, आपके पास अनावश्यक डेटा हो सकता है, लेकिन यह खोज योग्य होने के लिए एक तरह से संरचित है। ऊपर दिखाया गया एक अद्वितीय पहचानकर्ता है। एक अन्य व्यक्ति \ Company \ Name हो सकता है। यह कई अनुक्रमित होने के समान है।

— जेएफओ

Answer 3

यदि आप अक्सर कस्टम फ़ील्ड अनुरोधों में भाग लेने जा रहे हैं, तो मैं वास्तव में इसे डेटाबेस के समान ही मॉडल बनाऊंगा। प्रत्येक कस्टम फ़ील्ड के बारे में मेटाडेटा रखने वाली तालिका बनाएँ, CompanyCustomField (यह किससे संबंधित है, डेटा प्रकार, आदि) और एक अन्य तालिका CompanyCustomFieldValues ​​जिसमें CustomerId, FieldId और मान शामिल हैं। यदि आप Microsoft Sql सर्वर जैसी किसी चीज़ का उपयोग कर रहे हैं, तो मेरे पास एक sql_variant डेटाटाइप मान स्तंभ होगा।

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

यह गैर तुच्छ है, लेकिन इसमें हर नए कस्टम क्षेत्र के लिए डेटाबेस परिवर्तन / कोड परिवर्तन की आवश्यकता नहीं होने का लाभ है। कस्टम फ़ील्ड की किसी भी अन्य विशेषताओं को कोडित करने की आवश्यकता होगी (उदाहरण के लिए, यदि आप किसी स्ट्रिंग मान को फिर से लिखना चाहते हैं, या केवल कुछ श्रेणियों के बीच दिनांक की अनुमति देते हैं, या यदि आपको किसी अन्य कस्टम फ़ील्ड मान के आधार पर एक कस्टम फ़ील्ड को सक्षम करने की आवश्यकता है )।

Comments

धन्यवाद - मैं हालांकि इस तरह के दृष्टिकोण के बारे में - कृपया संपादन देखें। 2 समस्याएं: 1) डेटा पंक्तियों के रूप में बढ़ता है, जिसका अर्थ है कि उपयोगकर्ता की पूरी तस्वीर प्राप्त करने के लिए, आपको बहुत सारे जुड़ने होंगे। 2) "मूल्य" हमेशा सामान्य होने के लिए VARCHAR के रूप में संग्रहीत किया जाएगा, भले ही मूल्य वास्तव में इंट या बूलियन आदि हो

— noobcser

@noobcser पंक्तियों के रूप में बढ़ता हुआ डेटा वास्तव में मायने नहीं रखता है, क्योंकि सभी डेटाबेस पंक्तियों और जोड़ के आसपास डिजाइन कर रहे हैं। किसी भी घटना में आप इसके लिए कॉमन टेबल एक्सप्रेशंस का उपयोग करेंगे, जो इस प्रकार की चीज़ों में काफी अच्छे हैं। मुझे यकीन नहीं है कि यदि आप उस हिस्से को याद करते हैं जहां मैंने कहा था कि आप sql_variant का उपयोग मूल्य कॉलम के डेटा प्रकार के रूप में कर सकते हैं, जो उस मूल्य को संग्रहीत करता है जो आप उसमें टाइप करते हैं। जब मैं MS SQL सर्वर सुविधा नामों का नामकरण कर रहा हूं, तो मैं अन्य परिपक्व DBMS से इसी तरह की विशेषताओं की अपेक्षा करूंगा।

— एंडी

@noobcser FYI करें मैंने वास्तव में अपने करियर में इन आवश्यकताओं का बहुत बार सामना किया है और प्रत्येक प्रस्तावित समाधान के साथ अनुभव किया है, इसलिए मैं सुझाव दे रहा हूं जिसने मेरे अनुभव में सबसे अच्छा काम किया है। इस प्रकार की चीज़ों के लिए xml डेटा प्रकारों का उपयोग आंशिक रूप से इसलिए होता है कि मैं उस x एमएस को देशी डेटा प्रकार के रूप में जोड़ने से घृणा करता हूँ।

— एंडी

Answer 4

अन्य उत्तरों के लिए एक विकल्प के लिए एक टेबल है, जिसे profile_attrib कहा जाता है, या इसी तरह कि स्कीमा पूरी तरह से आपके एप्लिकेशन द्वारा प्रबंधित की जाती है।

जैसे ही कस्टम विशेषताएँ जोड़ी जाती हैं, आप ALTER TABLE profile_attrib ADD COLUMN like_movie TINYINT(1) उन्हें हटाने से रोक सकते हैं। यह लचीलापन प्रदान करते हुए, आपके जुड़ने को कम करेगा।

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

Comments

नियमित अभिव्यक्ति [^\w-]+को अच्छी तरह से करना चाहिए, ऐसा कुछ भी करने की अनुमति नहीं है 0-9A-Za-z_-- लेकिन हां, दुर्भावना या मूर्खता से बचाने के लिए स्वच्छता करना यहां आवश्यक है।

— नियमित जो

Answer 5

आपके प्रश्न के कई संभावित समाधान हैं। एक समाधान एक्सएमएल के रूप में अतिरिक्त एट्रिब्यूट्स को स्टोर करना है। XML को पाठ के रूप में संग्रहीत किया जा सकता है या यदि आपका डेटाबेस XML प्रकार (SQL सर्वर) के रूप में XML का समर्थन करने वाले डेटाबेस का उपयोग कर रहा है। पाठ के रूप में संग्रहीत करना आपकी क्वेरी करने की क्षमता को सीमित करता है (जैसे एक कस्टम विशेषता पर खोज), लेकिन यदि भंडारण और पुनर्प्राप्ति आपकी सभी आवश्यकता है तो इसका एक अच्छा समाधान है। यदि किसी को क्वेरी करने की आवश्यकता है, तो एक्सएमएल को एक्सएमएल प्रकार के रूप में संग्रहीत करना एक बेहतर विकल्प होगा (हालांकि यह अधिक विक्रेता विशिष्ट है)।

यह एक ग्राहक को किसी भी संख्या की विशेषताओं को स्टोर करने की क्षमता प्रदान करेगा, जिसमें ग्राहक तालिका पर एक अतिरिक्त कॉलम जोड़ा जाएगा। विशेषताओं को हैशसेट या शब्दकोश के रूप में संग्रहीत किया जा सकता है, एक प्रकार की सुरक्षा खो देगा क्योंकि सब कुछ एक स्ट्रिंग के साथ शुरू होगा, लेकिन अगर कोई दिनांक, संख्या, बूलियन के लिए मानक प्रारूप स्ट्रिंग लागू करता है, तो यह ठीक काम करेगा।

अधिक जानकारी के लिए:

https://msdn.microsoft.com/en-us/library/hh403385.aspx

@ WalterMitty का उत्तर भी मान्य है, हालांकि यदि किसी के पास अलग-अलग विशेषताओं वाले बहुत सारे ग्राहक हैं, तो वंशानुक्रम मॉडल का पालन करने पर कई तालिकाओं के साथ समाप्त हो सकता है। यह इस बात पर निर्भर करता है कि ग्राहकों के बीच कितनी कस्टम विशेषताएँ साझा की जाती हैं।

Comments

यह भी काम कर सकता है, लेकिन मुझे लगता है कि एक बार सीमित हो जाने के बाद आपको XML / JSON फ़ील्ड में संग्रहीत डेटा के विरुद्ध वास्तव में कुछ करने की आवश्यकता होती है।

— एंडी

@Andy - सच है, एक और परत है। क्वेरी DB और पार्स XML के रूप में सिर्फ क्वेरी DB का विरोध किया। मुझे नहीं पता कि क्या मैं इसे सीमित कहूंगा, बस अधिक बोझिल। लेकिन, यह विचार करने के लिए कुछ होगा कि क्या कस्टम विशेषताओं का बड़े पैमाने पर उपयोग किया गया था।

— जॉन रेन्नोर

टी-एसक्यूएल में एक्सएमएल / JSON कॉलम में कस्टम नाम पर तत्वों के खिलाफ नाम और क्वेरी के खिलाफ सामग्री को परिभाषित करना संभव है। यह मुश्किल नहीं है

— स्टीफन यॉर्क

Answer 6

आपको अपने डेटाबेस को सामान्य करना चाहिए जैसे कि आपके पास प्रत्येक अलग प्रकार की कंपनी प्रोफाइल के लिए 3 अलग-अलग टेबल हैं। अपने उदाहरण का उपयोग करते हुए, आपके पास कॉलम वाली तालिकाएँ होंगी:

USER_ID, LIKE_MOVIE, LIKE_MUSIC

USER_ID, FAVORITE_CUISINE

USER_ID, OWN_DOG, DOG_COUNT

यह दृष्टिकोण मानता है कि आप उस जानकारी को आकार देंगे जो एक कंपनी हाथ से पहले संग्रहीत करना चाहती है और यह अक्सर नहीं बदलेगी। यदि डेटा का आकार डिज़ाइन समय पर अज्ञात है, तो संभवतः उस JSON फ़ील्ड या नोस्कल डेटाबेस के साथ जाना बेहतर होगा।

Answer 7

एक कारण या किसी अन्य के लिए, डेटाबेस एक ऐसा क्षेत्र है जिसमें आंतरिक प्लेटफ़ॉर्म प्रभाव सबसे अधिक बार दिखाई देता है। यह केवल एंटी-पैटर्न पॉप अप करने का एक और मामला है।

इस मामले में, आप प्राकृतिक और सही समाधान से लड़ने की कोशिश कर रहे हैं। कंपनी ए के उपयोगकर्ता कंपनी बी के उपयोगकर्ता नहीं हैं, और उनके पास अपने स्वयं के क्षेत्रों के लिए अपनी टेबल होनी चाहिए।

आपका डेटाबेस विक्रेता आपको टेबल द्वारा चार्ज नहीं करता है, और आपको दो बार टेबल के लिए दो बार डिस्कस्पेस की आवश्यकता नहीं है (वास्तव में, दो टेबल होने से यह अधिक कुशल है क्योंकि आप बी के उपयोगकर्ताओं के लिए ए की विशेषताओं को संग्रहीत नहीं करते हैं। यहां तक ​​कि सिर्फ NULLs को संग्रहीत करना। जगह लेता है)।

बेशक, यदि पर्याप्त सामान्य क्षेत्र हैं, तो आप उन लोगों को साझा उपयोगकर्ता तालिका में शामिल कर सकते हैं, और कंपनी-विशिष्ट उपयोगकर्ता तालिकाओं में से प्रत्येक में एक विदेशी कुंजी है। यह इतनी सरल संरचना है कि कोई भी डेटाबेस क्वेरी ऑप्टिमाइज़र इसके साथ संघर्ष नहीं करता है। कोई भी आवश्यक JOIN तुच्छ है।

Comments

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

— एंडी

@ और: क्या लगता है? यदि आप एक ही तालिका में एक हजार अलग-अलग योजनाओं का मिश्रण करते हैं तो स्थिति और भी अकल्पनीय हो जाएगी! और हाँ, आपको शायद कस्टम फ़ील्ड के लिए कस्टम कोड की आवश्यकता है। फिर से यह सरल है, कठिन नहीं है, यदि प्रत्येक ग्राहक के पास एक साफ, अलग टेबल है। कंपनी X के खेतों को एक हजार अन्य लोगों से लेने की कोशिश एक खूनी गड़बड़ है।

— मैटलर्स

क्या आप मेरे जवाब या ग्राहक तालिका पर सभी अतिरिक्त कॉलम से निपटने के ओपी विचार का उल्लेख कर रहे हैं?

— एंडी

यहां लक्ष्य एक बनाए रखने योग्य और मापनीय समाधान खोजना है। प्रति ग्राहक तालिका बनाना निश्चित रूप से इसके विपरीत है। हर बार जब आप एक नए ग्राहक पर सवार होते हैं, तो यह यथार्थवादी नहीं होता है: एक टेबल टेबल बनाएं, अपने कोड (एंटिटी ऑब्जेक्ट्स) को अपडेट करें और फिर से तैनात करें।

— tsOverflow

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

— कठिनता

Answer 8

मेरा समाधान यह मानता है कि आप इस क्वेरी को एक प्रोग्राम से बुला रहे हैं और आपको पोस्ट प्रोसेसिंग करने में सक्षम होना चाहिए। आपके पास निम्नलिखित कॉलम हो सकते हैं:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_VALUES

CUSTOM_VALUES स्ट्रिंग स्ट्रिंग कुंजी और मान जोड़े का होगा। कुंजी कॉलम नाम होगा और मान स्तंभ मान होगा

LIKE_MOVIE;yes;LIKE_MUSIC;no;FAV_CUISINE;rice

इस CUSTOM_VALUES में आप केवल उन सूचनाओं को सहेजेंगे जो मौजूद हैं। जब आप प्रोग्राम से क्वेरी करते हैं तो आप इस स्ट्रिंग को विभाजित कर सकते हैं और इसका उपयोग कर सकते हैं।

मैं इस तर्क का उपयोग कर रहा हूं और यह ठीक काम करता है, बस इसके लिए आपको कोड में फ़िल्टरिंग तर्क को लागू करना होगा और क्वेरी में नहीं।