क्या आपके पास अच्छी डीबी स्कीमा में समान संरचना वाले 2 टेबल हो सकते हैं?

Question

2 टेबल:
- विचारों
- डाउनलोड

समान संरचना:
ITEM_ID, user_id, समय

मैं चिंतित किया जाना चाहिए?

Answer 1

मुझे नहीं लगता कि एक समस्या है, प्रति से।

जब डीबी डिज़ाइन करते हैं तो बहुत सारे पैरामीटर होते हैं, और कुछ (उदा .: प्रदर्शन) प्राथमिकता ले सकते हैं।

बिंदु में मामला: भले ही संरचनाएं (और मुझे लगता है कि अनुक्रमण) समान हैं, शायद "विचारों" में अधिक रिकॉर्ड हैं और अधिक बार उपयोग किया जाएगा। यह अकेले ही एक अच्छा कारण हो सकता है कि इसे डाउनलोड से रिकॉर्ड के साथ बोझ न दें।

इसके अलावा, तथ्य यह है कि वे अब इंडेंटिकल हैं इसका मतलब यह नहीं है कि वे भविष्य में होंगे: विचार और डाउनलोड अलग-अलग हैं, आखिरकार या बाद में एक या दोनों अतिरिक्त क्षेत्र या दो विकसित कर सकते हैं।

Answer 2

ये तालिकाएं अभी भी समान हैं लेकिन भविष्य में स्कीमा परिवर्तन हो सकती हैं। यदि वे 2 अलग-अलग अवधारणाओं का प्रतिनिधित्व करते हैं तो उन्हें अलग रखना अच्छा होता है। क्या होगा यदि आप किसी अन्य तालिका से डाउनलोड टेबल पर एक विदेशी कुंजी चाहते थे, लेकिन दृश्य तालिका नहीं, अगर वे वही टेबल थे तो आप ऐसा नहीं कर सके।

Answer 3

ई/आर मॉडलिंग दृष्टिकोण से मुझे उसमें कोई समस्या नहीं दिखाई देती है, जब तक कि वे दो अर्थात् अलग-अलग इकाइयों का प्रतिनिधित्व करते हैं। ,

• आप एक दूसरे से स्वतंत्र रूप से उन तालिकाओं क्वेरी करने के लिए योजना बना रहे हैं उन्हें अलग एक अच्छा विकल्प
रखने जाता है:

देखने का एक कार्यान्वयन की दृष्टि से, यह वास्तव में कैसे आपको लगता है कि डेटा को क्वेरी करने की योजना पर निर्भर करता है

• आप एक discriminator स्तंभ के साथ एक एकल तालिका में उन्हें भंडारण भेद करने के लिए अपने प्रकार

जब विचार कर उन्हें int मजबूत करने के लिए है कि क्या विचार करना चाहिए आप उन तालिकाओं एक साथ (शायद एक में शामिल हों आपरेशन का एक संघ के साथ) क्वेरी करने के लिए योजना बना रहे हैं oa एकल तालिका आप भी तरह खाते में अन्य कारकों में रखना चाहिए:

• डेटा की मात्रा हर तालिका
• दर, जिस पर डेटा हर तालिका
• पढ़ें/लिखें संचालन के अनुपात निष्पादित में बढ़ता में संग्रहीत प्रत्येक तालिका पर

Answer 4

मुझे लगता है कि उत्तर "यह निर्भर करता है" होना चाहिए। जैसा कि किसी और ने इंगित किया है, यदि एक या दोनों टेबलों की स्कीमा विकसित होने की संभावना है तो नहीं। मैं अन्य मामलों के बारे में सोच सकता हूं (ऐप/उपयोगकर्ताओं को एक या दूसरे तक पहुंचने की अनुमति देकर सुरक्षा मॉडल को सरल बनाना)।

यह कहकर, मैं एक विरासत डीबी के साथ काम करता हूं जहां यह एक समस्या है। हमारे पास ग्राहक चालान के लिए कई समान सारणीएं हैं। प्रसंस्करण जीवन चक्र में विभिन्न चरणों में डेटा वास्तव में तब स्थानांतरित हो जाता है। डेटा तक पहुंचने का प्रयास करते समय यह जटिल गड़बड़ी करता है।इसे मूल स्कीमा में राज्य ध्वज द्वारा आसानी से हल किया गया होगा, लेकिन अब हमारे पास बहु-तालिका संस्करण के खिलाफ 20+ वर्ष कोड लिखा गया है।

संक्षिप्त उत्तर: इस बात पर निर्भर करता है कि वे एक ही स्कीमा क्यों हैं :)।

Answer 5

क्रिस डेट और डेव मैकगोवरन ने "Principle of Orthogonal Design" को औपचारिक रूप दिया। इसका मतलब यह है कि डेटाबेस डिज़ाइन में आपको दो अलग-अलग रिवर्स में एक ही टुपल की अनुमति देने की संभावना से बचना चाहिए। इसका उद्देश्य कुछ प्रकार की अनावश्यकता और अस्पष्टता से बचने का लक्ष्य है जो परिणामस्वरूप हो सकता है।

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

Answer 6

यह संदर्भ पर निर्भर करता है - View क्या है और Download क्या है? क्या Download एक View इंगित करता है (यह और कैसे डाउनलोड किया जाएगा)?

यह संभव है कि आपके पास अच्छी तरह से परिभाषित, अलग अवधारणाएं हैं - लेकिन यह एक गंध है जिसे मैं आगे की जांच करना चाहता हूं। ऐसा लगता है कि एक दृश्य और डाउनलोड किसी भी तरह से संबंधित हैं, लेकिन आपका मॉडल कुछ भी नहीं दिखाता है।

Answer 7

क्या आप कह रहे हैं कि दोनों तालिकाओं में 'item_id' प्राथमिक कुंजी है? इस मामले में, फ़ील्ड का एक ही नाम है, लेकिन इसका कोई अर्थ नहीं है। एक 'view_id' है, और दूसरा एक 'download_id' है। इस तरह की गलतफहमी से बचने के लिए आपको अपने खेतों का नाम बदलना चाहिए।