क्या हमें कभी किसी डेटाबेस में डेटा डिलीट करना चाहिए?

39

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

क्या यह सच है? यदि हां, तो आईबीएम जैसी बड़ी कंपनी सौ या अधिक वर्षों के लिए अपने डेटा को कैसे संभालती है?

database maintenance

— fuddin
स्रोत

2

कृपया स्पष्ट करें - क्या आप पूछ रहे हैं कि क्या आपको एसक्यूएल में डिलीट कमांड जारी करना चाहिए या नहीं, या आप पूछ रहे हैं कि क्या अंतर्निहित डेटाबेस इंजन वास्तव में डिलीट हुए डेटा को डिलीट कर देता है?

— ग्रैंडमास्टरबी

4

@StartupCrazy: वह टिप्पणी मेरे लिए कुछ भी स्पष्ट नहीं करती है।

— डॉक ब्राउन

6

"हम" से कौन अभिप्राय है?

— डायनामिक

3

मुझे सब कुछ लगभग अस्पष्ट रूप से रखना बहुत पसंद है। लेकिन मुझे नहीं पता कि आप किस व्यवसाय में हैं, लेकिन कुछ डेटा आपको कुछ निर्धारित समय तक रखने के लिए कानूनी रूप से आवश्यक हैं और कुछ डेटा आपको कुछ निर्धारित समय के बाद हटाने के लिए कानूनी रूप से आवश्यक हैं।

— पीटर बी

6

यह निर्भर करता है कि यह किस तरह का डेटा है। कुछ मामलों में आपको इसे कानूनी कारणों से हटाना होगा।

— कोडइन्कॉउंस

63

जैसा कि इन सभी बातों का जवाब है "यह निर्भर करता है"।

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

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

हालाँकि, यदि डेटा अल्पकालिक है या आसानी से बनाया गया है तो आप वास्तव में डेटा को हटाने का निर्णय ले सकते हैं।

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

समान रूप से ऐसे नियम हो सकते हैं जिनके लिए आपको डेटा को हटाने की आवश्यकता नहीं है, इसलिए किसी भी नियामक अधिकारियों के साथ कुछ भी जांचने से पहले आपको कानून का पालन करने के लिए क्या करने की आवश्यकता है।

— क्रिसफ
स्रोत

8

कुछ एप्लिकेशन क्षेत्रों (लेखांकन, चिकित्सा उपकरणों) को संभवतः ऑडिटिंग आवश्यकताओं के कारण डेटा को हटाने की आवश्यकता नहीं है।

— पॉल

3

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

— गैविन

डेटाबेस में कुछ जगह खाली करने से उसका प्रदर्शन बढ़ जाता है?

— viveksinghggits

17

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

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

— TMN
स्रोत

1

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

— कीथ्स

यही मैं कह रहा था, सिस्टम को कुछ प्रकार के समाप्ति संकेतक के साथ डिज़ाइन करने की आवश्यकता है। इन संकेतकों की अनुपस्थिति में (जो कि कई कंपनियों के मामले में है), यह पहचानने का कोई तरीका नहीं है कि कौन से रिकॉर्ड सुरक्षित रूप से हटाए जा सकते हैं।

— TMN

12

इसके लिए पहले से ही बहुत सारे अच्छे उत्तर हैं जो "परिस्थिति पर निर्भर करता है" के लिए बहुत ज्यादा उबलते हैं, और मैं उन लोगों के लिए कुछ भी नहीं जोड़ सकता।

एक बात जिसका उल्लेख नहीं किया गया है, हालाँकि, मुझे लगता है कि इसका उल्लेख करने की आवश्यकता है, यह है कि आपको कभी भी उन प्राथमिक कुंजियों का पुन: उपयोग नहीं करना चाहिए जिन्हें किसी अनुक्रम या AUTO_INCREMENT प्रणाली द्वारा उत्पन्न किया गया है।

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

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

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

इससे भी बदतर, अगर आप प्रिंटर 13 को हटाते हैं और अंतराल को भरने के लिए उसके बाद आने वाले सभी प्रिंटर को फेरबदल करते हैं, तो क्या होता है? प्रिंटर 14 (कुछ पुराना पुराना डॉट मैट्रिक्स) प्रिंटर 13 बन जाता है, प्रिंटर 15 प्रिंटर 14 हो जाता है।

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

आपको एक ऑटो-इन्क्रीमेंट सिस्टम द्वारा सौंपी गई आईडी के बारे में सोचना चाहिए, वे अपरिवर्तनीय हैं और उनका पुन: उपयोग नहीं किया जा सकता है, भले ही वह चीज जो आईडी मौजूद होने का संकेत देती हो। कुछ लोग दावा करते हैं कि वे आईडी चलाने के बारे में चिंता नहीं करना चाहते हैं, लेकिन 32 बिट सिस्टम और हस्ताक्षरित आईडी के साथ, अभी भी 2 बिलियन या इतनी आईडी उपलब्ध हैं। यदि आप आईडी कॉलम को अहस्ताक्षरित कर सकते हैं तो यह दोगुना होकर 4 बिलियन हो जाता है, और 64 बिट सिस्टम पर उपलब्ध आईडी की संख्या शाब्दिक रूप से आकाश में सितारों की संख्या से अधिक है। आप आईडी से बाहर नहीं जा रहे हैं।

— GordonM
स्रोत

3

ज्यादातर मामलों में आपको ऑटो जेनरेट किए गए नंबरों के बारे में नहीं सोचना चाहिए, वे अर्थहीन हैं और उपयोगकर्ता के सामने नहीं आने चाहिए। आपको यह कहते हुए संदेश कभी नहीं मिलना चाहिए कि प्रिंटर 13 स्याही पर कम है, हो सकता है "सूट 13 में प्रिंटर", लेकिन ऑटो उत्पन्न संख्या नहीं।

— jmoreno

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

— गॉर्डन मॉर्निंग

यह केवल एक RI समस्या है यदि आपके पास विदेशी कुंजी बाधाएं नहीं हैं और इसके बजाय विदेशी कुंजियाँ हैं। जिस स्थिति में आपको संभवतः बड़ी समस्याएं हैं।

— jmoreno

आपको आश्चर्य होगा कि मैं अभी भी कितने mysql डेटाबेस चला रहा हूँ, ठीक उसी तरह। बहुत सारे डेवलपर्स को लगता है कि वे अपने सभी सुविधाओं का उपयोग नहीं करते हैं।

— गॉर्डन

4

यहाँ पहले से ही बहुत अच्छे जवाब हैं। मैं केवल एक स्थिति जोड़ना चाहता हूं जिसका किसी ने अभी तक उल्लेख नहीं किया है:

संवेदनशील डेटा । यदि उपयोगकर्ता इसे हटाता है, तो आप वास्तव में इसे हटा सकते हैं!

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

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

इसलिए मैं खुद से पूछूंगा: क्या उपयोगकर्ता (या कोई और, उदाहरण के लिए सरकार) पागल होगा यदि मैं उन्हें विश्वास दिलाता हूं कि डेटा हटा दिया गया है, लेकिन वास्तव में मुझे अभी भी मिल गया है और इसे किसी भी समय पुनर्स्थापित कर सकता है?

— जेकब
स्रोत

दिलचस्प। क्या वाकई बड़ी कंपनियां इस पर अमल करती हैं?

— फुद्दीन

2

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

— माइक पार्टरिज

2

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

— TMN

1

क्रेडिट कार्ड नंबर। कभी भी संग्रहित नहीं करना चाहिए। दरअसल MUST को कभी स्टोर नहीं किया जाना चाहिए। यदि कोई ग्राहक मुझे ईमेल में अपना क्रेडिट कार्ड नंबर भेजने के लिए पर्याप्त बेवकूफ है, तो मुझे एक वास्तविक समस्या है। इससे छुटकारा पाने के तरीके होने चाहिए।

— gnasher729

यूरोपीय संघ GDPR उनके संबंध भेजता है।

— डिस्प्लेनेम

3

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

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

हालांकि, हमेशा की तरह, सटीक उत्तर वास्तव में विशिष्ट स्थिति पर निर्भर करता है।

— मैट एस
स्रोत

1

मैं कुछ वर्षों के लिए एक विदेशी मुद्रा आवेदन पर काम कर रहा हूं जहां यह आया था। वर्षों से एकत्र किए गए डेटा का प्रदर्शन पर प्रभाव (कहें कि घातांक) था।

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

— dbalakirev
स्रोत

1

भविष्य में जरूरत पड़ने पर अधिकांश मामलों में आपको सिर्फ डेटा रखना चाहिए। आप जिस व्यवसाय के लिए काम करते हैं, वे अपने निर्णयों को आधार बनाने के लिए ऐतिहासिक डेटा को देखना चाह सकते हैं, जिस पर एक निश्चित दिशा में कोमपनी को बढ़ावा मिलेगा।

आपको प्रत्येक तालिका में 'Date_Time_Removed' कॉलम को जोड़ना चाहिए और फिर पंक्ति को हटाने के लिए भौतिक रूप से हटाने के बजाय, आपने दिनांक और समय निर्धारित किया है कि पंक्ति को वस्तुतः हटा दिया गया है। फिर अपनी संग्रहीत प्रक्रियाओं या sql में आप 'Date_Time_Removed' कॉलम में फ़ैक्टर करेंगे उदा जैसे तालिका 1 से blah चुनें जहाँ date_time_removed अशक्त है

बेशक एक डेटाबेस में गलती से जोड़े गए पंक्तियों को स्थायी रूप से हटा दिया जाना चाहिए, विशेष रूप से डेटा का परीक्षण करें।

भविष्य में वेयरहाउसिंग के लिए आपको अपने सभी कानूनी डेटा को रखने का विकल्प भी रखना होगा।

— जूलियन मुमेरी
स्रोत

0

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

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

— कोरल डो
स्रोत