अप्रचलित डेटाबेस कॉलम को रिटायर करने के आसपास के सर्वोत्तम अभ्यास क्या हैं? [बन्द है]

14

बंद हो गया । इस प्रश्न पर अधिक ध्यान देने की आवश्यकता है । यह वर्तमान में उत्तर स्वीकार नहीं कर रहा है।

इस प्रश्न को सुधारना चाहते हैं? प्रश्न को अपडेट करें ताकि यह इस पोस्ट को संपादित करके केवल एक समस्या पर केंद्रित हो ।

2 साल पहले बंद हुआ ।

मैं एक एप्लिकेशन डिजाइन कर रहा हूं, जो शुरुआती चरण में ग्राहकों से डेटा ए, बी और सी एकत्र करेगा, लेकिन बाद में इसके बजाय डेटा ए, बी और डी इकट्ठा करेगा।

A, B, C और D बहुत संबंधित हैं और अभी एक ही डेटाबेस PostgreSQL टेबल T के कॉलम के रूप में मौजूद हैं ।

एक बार सी की आवश्यकता नहीं है, मैं अपने आवेदन (मैं Django ORM का उपयोग करता हूं ) से इसके संदर्भ निकालना चाहता हूं , लेकिन मैं पहले से दर्ज किए गए डेटा को रखना चाहता हूं। ऐसा करने का सबसे अच्छा तरीका क्या है?

मैंने एबीडी के लिए एक नई तालिका बनाने के बारे में सोचा है, लेकिन इसका मतलब है कि टेबल टी को संदर्भित करने वाली किसी भी पंक्तियों के साथ समस्या हो सकती है।

मैं कॉलम सी को केवल साथ छोड़ सकता था, और कोड में इसके संदर्भ हटा सकता था, जिससे मौजूदा डेटा बच सकता है।

क्या कोई बेहतर विकल्प है जो मैं नहीं देख रहा हूं?

कुछ अतिरिक्त विवरण:

पंक्तियों की संख्या बड़ी नहीं होगी, सबसे अधिक संभावना 1-2 प्रति उपयोगकर्ता। यह एक बड़े पैमाने पर बाजार अनुप्रयोग है, लेकिन जब तक मैं सी से डी पर स्विच करता हूं, तब तक उपयोगकर्ताबेस बहुत बड़ा नहीं होगा। सी और डी की संभावना एक ही समय में एकत्र नहीं की जाएगी, हालांकि यह एक संभावना है। C और D एक नहीं, बल्कि कई स्तंभों का प्रतिनिधित्व करते हैं।

— जद एस
स्रोत

मुझे लगता है कि यह दृष्टिकोण करने का सही तरीका इस बात पर निर्भर करता है कि क्या आपको {A, B, C}, और {A, B, D} से एकत्र की गई पंक्तियों के बीच अंतर करने की आवश्यकता है, और यदि आपका वर्तमान डेटा है तो मॉडल यह अनुमति देता है। और यह इस बात पर भी निर्भर करेगा कि आप {A, B, C} से एकत्रित उन पंक्तियों के साथ क्या करने जा रहे हैं - एप्लिकेशन का नया संस्करण उन्हें खाली "D" के साथ {A, B, D} के रूप में दिखाता है, लेकिन a उपयोगकर्ता कॉलम C की सामग्री को नहीं देखता है, वह db से उस पंक्ति को हटाने के लिए लुभा सकता है (यदि एप्लिकेशन पंक्तियों को हटाने की अनुमति देता है), क्योंकि वह सामग्री नहीं देखता है।

— डॉक ब्राउन

8

"सबसे अच्छा अभ्यास" एक बुरी बात पर सवाल क्यों पूछ रहा है?

क्या कभी सी और डी के साथ कोई पंक्तियाँ एकत्र की जाती हैं? या यह हमेशा A, B, C, Null या A, B, Null, D होगा? यदि आपके पास छोटी अवधि के लिए एक ही पंक्तियों पर सी, डी है ... ए, बी, सी और ए, बी, डी टेबल न होने का कारण क्या है? क्या हम बात कर रहे हैं ... डेटा की सैकड़ों पंक्तियाँ? लाखों? अरबों? प्रतिक्रिया समय एक कारक है? विवरण के बहुत सारे जो प्रत्येक स्थिति को विशिष्ट बनाते हैं ...

— वर्नरसीडी

@WernerCD ने प्रश्न में मेरे मामले पर कुछ विवरण जोड़े

— Jad S

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

— थाइलॉन

31

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

— केविन क्लाइन
स्रोत

1

आप थोड़ी देर के बाद बहुत सारे नल के स्तंभों के साथ समाप्त हो सकते हैं

— एवान

8

शायद वे स्टेक्सएक्सचेंज पर सबसे अच्छा अभ्यास दृष्टिकोण के लिए पूछ सकते हैं .... जब ऐसा होता है

— ईवान

8

मुझे लगता है कि इस तरह के जवाब से मेरी झुंझलाहट है, निश्चित रूप से आप इसे दूर कर सकते हैं, लेकिन इसके तकनीकी ऋण। आखिरकार आप एक वास्तविक समाधान चाहते हैं और आपको सभी नए कामों के बारे में नहीं बताना है कि आपकी कंपनी में अब तक की सबसे बड़ी तकनीकी कंपनी के पास बेतरतीब कॉलम क्यों हैं जो आपके db के माध्यम से बिखरे हुए हैं

— Ewan

1

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

— जद एस

3

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

— थॉमस डब्ल्यू

8

ठीक है, इसलिए आपकी स्थिति यह है कि आप चाहते हैं कि पुरानी पंक्तियों में संपत्ति C हो, लेकिन नए नहीं।

यह क्लास इनहेरिटेंस रिलेशनशिप होने के बराबर है

class All
{
    string A;
    string B;
}

class Old : All
{
    string C;
}

class New : All
{
    string D;
}

जो आप 1 से 1 संबंधों वाले तीन तालिकाओं के साथ डेटाबेस पर प्रतिनिधित्व करेंगे

table All
    id varchar
    A varchar
    B varchar

table Old
    id varchar
    C  varchar

table New
    id varchar
    D  varchar

इसलिए आप नई पुरानी तालिका बनाने के लिए एक माइग्रेशन स्क्रिप्ट बना सकते हैं, उसमें आईडी और सी डेटा कॉपी कर सकते हैं और ऑल टेबल से सी कॉलम हटा सकते हैं।

नए कोड के साथ अपने कोड को आवश्यकतानुसार अपडेट करना;

वैकल्पिक रूप से, यदि आपको पुराने C डेटा को क्वेरी करने में सक्षम होने की आवश्यकता है, तो आप A, B, C के साथ एक नया आर्काइव टेबल बना सकते हैं और सभी डेटा को कॉपी कर सकते हैं और C कॉलम को हटा सकते हैं, D कॉल को अपनी 'लाइव' तालिका में जोड़ सकते हैं।

— ईवान
स्रोत

1

यदि मैं तालिकाओं को विभाजित करता हूं, तो मैं उनमें से तीन ले लूंगा: {A, B} {C} {D}

— Aconcagua

उदाहरण से मेल नहीं खाता है?

— इवान

रुको। मुझे याद है

— ईवान

2

यदि डेटा संग्रहण एक चिंता का विषय हो सकता है, तो तालिकाओं को विभाजित करें: कुंजी / ए / बी कुंजी / सी कुंजी / डी

आप या तो एक दृश्य (db में डेटा स्थान की परिभाषा) के माध्यम से या ORM परिभाषा को बदलकर प्रदर्शन कर सकते हैं।

यह सबसे अधिक प्रदर्शन करने वाला नहीं है (एक शामिल है), लेकिन यह अंतर्निहित भंडारण को बदलने के बिना समय के ए / बी / सी / डी के किसी भी संयोजन को प्रस्तुत कर सकता है और आपके वास्तविक पहुंच पैटर्न के आधार पर यह पर्याप्त हो सकता है।

उत्पादन प्रणाली में डाउनटाइम, रिस्ट्रक्चर टेबल आदि लेने की क्षमता से आप भाग्यशाली नहीं हो सकते।

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

वास्तव में मुझे लगता है कि आपका निर्णय वास्तविक दुनिया की बहुत सारी चिंताओं को प्रतिबिंबित करेगा: 1) सी एंड डी 2 के लिए डेटाटैपीज़ सी एंड डी 2) क्या हैं जो रिश्तेदार डेटा वॉल्यूम के लिए एकत्र किए गए हैं। विशुद्ध रूप से सी या डी प्रविष्टियों की तुलना में सी / डी डेटा के सापेक्ष ओवरलैप। 4) डाउनटाइम / रखरखाव खिड़की की उपलब्धता और अवधि 5) अद्यतन करने योग्य विचारों के लिए डीबीएमएस समर्थन 6) ओआरएम बनाम डीबी भौतिक संरचना विवरण रखने की वांछनीयता बनाम इसे डीबी में विचारों / कार्यों के माध्यम से प्रस्तुत करके पारदर्शी बना देता है (जहां यह सभी एक्सेस करने के लिए समान है) अनुप्रयोग, केवल वर्तमान एक नहीं)

(1), (3) के लिए थोड़ा ओवरलैप और (4) के लिए छोटे ओवरलैप, (5) के लिए आदर्श रूप से, (5) और (6) में डेटा तक पहुँचने वाले कई अनुप्रयोगों के साथ आदर्श रूप से मेरे जवाब को प्राथमिकता दी गई।

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

— सिमोन कोलमैन
स्रोत

1

संदर्भों को हटाना और डेटा को अनाथ करना एक कम जोखिम वाला विकल्प है।

डेटा के हमेशा अज्ञात 'बैकडोर' उपयोग संभव हैं जो स्तंभ को हटाकर उजागर करना महत्वपूर्ण हो सकता है या नहीं।

स्तंभ C की सामग्री के आधार पर एक मामूली प्रदर्शन समस्या हो सकती है जब DB आंतरिक रूप से पूर्ण तालिका स्कैन करता है या जोड़ के दौरान पूरे तालिका को स्मृति में खींचने का प्रयास करता है यदि अनुकूलक इसे अनुक्रमित करने की तुलना में अधिक कुशल होने के रूप में देखता है।

एप्लिकेशन चयनित स्तंभों के बजाय पूरी तालिका को एक बार पढ़ रहे होंगे - लेकिन यदि आप विशेष रूप से ORM का उपयोग कर रहे हैं तो यह संभावना नहीं है।

— amelvin
स्रोत

1

यहाँ पर विचार करने के लिए बहुत सी बातें लेकिन आप सीधे तालिका में परिवर्तन करने के बजाय तालिका को ओवरले करने के लिए एक दृश्य जोड़ने पर विचार करना चाह सकते हैं। इस तरह, यह केवल दृश्य है जिसे बदलने की आवश्यकता है।

मैं Django ORM नहीं जानता, लेकिन यह एक संभावना हो सकती है।

— रोबी डी
स्रोत

2

ओपी ने कहा कि वे Postgres का उपयोग कर रहे हैं।

— ट्रिपहाउंड

धन्यवाद - एक टैग नहीं देखा। मैं

— रोबी डी

0

आपके पास कॉलम ए, बी, सी के साथ एक टेबल ए है।
कॉलम ए, बी, डी के साथ एक नया टेबल बी बनाएं।
अपने डेटा को तालिका बी में माइग्रेट करें।
अपनी विदेशी कुंजियों को टेबल A से टेबल B पर ले जाएं।

अब आप टेबल बी का उपयोग कर सकते हैं और आपके पास अभी भी संदर्भ के लिए अपना पुराना डेटा है।

— Carra
स्रोत