เราควรลบข้อมูลในฐานข้อมูลหรือไม่?

39

ฉันยังใหม่กับฐานข้อมูลและพยายามเข้าใจแนวคิดพื้นฐาน ฉันได้เรียนรู้วิธีการลบข้อมูลในฐานข้อมูล แต่หนึ่งในเพื่อนของฉันบอกฉันว่าคุณไม่ควรลบข้อมูลในฐานข้อมูล หากไม่ต้องการใช้อีกต่อไปควรทำเครื่องหมายหรือตั้งค่าสถานะเป็น 'ไม่ใช้งาน'

มันเป็นเรื่องจริงเหรอ? ถ้าเป็นเช่นนั้น บริษัท ใหญ่อย่าง IBM จะจัดการกับข้อมูลของพวกเขาเป็นเวลาหนึ่งร้อยปีหรือมากกว่า

database maintenance

— fuddin
แหล่งที่มา

2

โปรดอธิบาย - คุณกำลังถามว่าคุณควรออกคำสั่งลบใน SQL หรือไม่หรือคุณกำลังถามว่ากลไกฐานข้อมูลพื้นฐานลบข้อมูลที่ถูกทำเครื่องหมายว่าถูกลบหรือไม่?

— GrandmasterB

4

@StartupCrazy: ความคิดเห็นนั้นไม่ได้อธิบายอะไรสำหรับฉัน

— Doc Brown

6

ใครคือคนที่มีความหมายโดย "เรา"

— แบบไดนามิก

3

ฉันชอบเก็บทุกอย่างไว้เกือบจะครอบงำ แต่ฉันไม่ทราบว่าคุณเป็นธุรกิจประเภทใด แต่มีข้อมูลบางส่วนที่คุณต้องใช้ตามกฎหมายเพื่อรักษาระยะเวลาที่กำหนดไว้และข้อมูลบางส่วนที่คุณถูกต้องตามกฎหมายต้องลบออกหลังจากเวลาที่กำหนด

— Pieter B

6

ขึ้นอยู่กับประเภทของข้อมูล ในบางกรณีคุณต้องลบด้วยเหตุผลทางกฎหมาย

— CodesInChaos

63

ทุกสิ่งเหล่านี้คำตอบก็คือ "มันขึ้นอยู่กับ"

หากผู้ใช้มีแนวโน้มที่จะต้องการข้อมูลกลับมาแสดงว่าเพื่อนของคุณถูกต้องคุณไม่ได้ลบจริงๆเพียงแค่ทำเครื่องหมายบันทึกว่า "ลบ" วิธีนี้เมื่อผู้ใช้เปลี่ยนใจคุณสามารถกู้คืนข้อมูลได้

อย่างไรก็ตามหากข้อมูลที่ถูกลบนั้นมีอายุมากกว่าช่วงเวลาที่แน่นอน (ตัวอย่างเช่นปี) คุณอาจตัดสินใจที่จะลบมันออกจากตารางจริง แต่ควรเก็บไว้ในตารางเก็บถาวรหรือแม้กระทั่งสำรองข้อมูลหากผู้ใช้ต้องการ มันกลับมา ด้วยวิธีนี้คุณสามารถรักษาปริมาณข้อมูล (สดและลบล่าสุด) ให้น้อยที่สุด

อย่างไรก็ตามหากข้อมูลไม่ถาวรหรือสร้างใหม่ได้ง่ายคุณอาจตัดสินใจลบข้อมูลจริง

มีข้อมูลประเภทหนึ่งที่คุณต้องลบ - และนั่นคือข้อมูลส่วนบุคคลที่ผู้ใช้ไม่ต้องการให้คุณเก็บอีกต่อไป อาจมีกฎหมายท้องถิ่น (เช่นในสหภาพยุโรป) ที่ทำให้ข้อกำหนดนี้บังคับ (ขอบคุณGavin )

อาจมีกฎที่คุณไม่ต้องลบข้อมูลดังนั้นก่อนตัดสินใจตรวจสอบอะไรกับหน่วยงานกำกับดูแลในสิ่งที่คุณต้องทำเพื่อให้สอดคล้องกับกฎหมาย

— ChrisF
แหล่งที่มา

8

บางส่วนของแอปพลิเคชั่น (การบัญชีอุปกรณ์การแพทย์) อาจต้องการข้อมูลที่ไม่ถูกลบเนื่องจากข้อกำหนดการตรวจสอบ

— พอล

3

ในบางสถานการณ์คุณต้องลบข้อมูลตัวอย่างคือสิ่งที่เกี่ยวข้องกับข้อมูลส่วนบุคคลของผู้ใช้ กฎหมายของสหภาพยุโรป (และอื่น ๆ ) ระบุว่าผู้ใช้ควรมีสิทธิ์ร้องขอให้ลบข้อมูลของตน ในกรณีเช่นนี้ข้อมูลนี้จะต้องถูกลบออกไปและไม่ได้ตั้งค่าสถานะเป็นไม่ใช้งานอีกต่อไป หลังจะเป็นการละเมิดกฎหมายความเป็นส่วนตัว

— กาวินโคตส์

การเพิ่มพื้นที่ว่างในฐานข้อมูลจะเพิ่มประสิทธิภาพของฐานข้อมูลหรือไม่

— viveksinghggits

17

นี่เป็นปัญหาสำคัญสำหรับ บริษัท จำนวนมาก ไม่มีวิธีใดที่จะตรวจสอบว่ามีการใช้ข้อมูลใดอยู่จริงดังนั้นจึงอยู่ในฐานข้อมูล การลบข้อมูลและการเก็บถาวรจำเป็นต้องเป็นส่วนหนึ่งของการออกแบบระบบขนาดใหญ่ทุกครั้ง แต่ไม่ค่อยมี บริษัท ส่วนใหญ่ใช้ชีวิตอยู่กับมันซื้อดิสก์ที่มีขนาดใหญ่ขึ้นและปรับแต่งแบบสอบถามและดัชนีเพื่อรักษาประสิทธิภาพจนกว่าพวกเขาจะเปลี่ยนระบบจากนั้นพวกเขาก็ต้องใช้ความพยายามอย่างมากในการระบุข้อมูลปัจจุบันแล้วย้ายข้อมูลเหล่านั้นไปยังระบบใหม่

ใช่คุณควรลบข้อมูลออกจากฐานข้อมูลของคุณ แต่มักจะไม่ง่ายที่จะบอกได้ว่าเมื่อไร

— TMN
แหล่งที่มา

1

"ไม่มีทางที่จะตัดสินใจได้อย่างชัดเจนว่าข้อมูลใดที่ใช้งานจริง" - ฉันไม่เห็นด้วย เขตข้อมูลบิต "IsDeleted" ในแต่ละตารางเป็นวิธีที่ค่อนข้างสะอาดในการระบุระเบียนที่ไม่เกี่ยวข้องอีกต่อไป คำถามส่วนใหญ่ที่โพสต์เช่นวิธีการเรียงซ้อนการลบยังมีอยู่ในรูปแบบการลบทางกายภาพและคำตอบนั้นขึ้นอยู่กับตัวแบบข้อมูลและไม่ว่าคุณจะให้ความสำคัญกับขนาดของพื้นที่จัดเก็บหรือประสิทธิภาพมากขึ้น

— KeithS

นั่นคือสิ่งที่ฉันพูดระบบจะต้องได้รับการออกแบบด้วยตัวบ่งชี้การหมดอายุบางประเภท ในกรณีที่ไม่มีตัวบ่งชี้เหล่านี้ (ซึ่งเป็นกรณีของ บริษัท จำนวนมาก) ไม่มีวิธีระบุว่าระเบียนใดที่สามารถลบได้อย่างปลอดภัย

— TMN

12

มีคำตอบที่ดีมากมายเกี่ยวกับสิ่งนี้ที่ต้มลงไปที่ "ขึ้นอยู่กับสถานการณ์" และฉันไม่สามารถเพิ่มอะไรให้กับสิ่งเหล่านั้นได้

สิ่งหนึ่งที่ไม่ได้กล่าวถึง แต่ฉันคิดว่าต้องพูดถึงคือคุณไม่ควรนำคีย์หลักมาใช้ซ้ำซึ่งสร้างขึ้นตามลำดับหรือระบบ AUTO_INCREMENT

เมื่อคุณลบรายการที่ได้รับการกำหนดคีย์หลักโดยระบบดังกล่าวจะมีช่องว่างในคอลัมน์คีย์หลักจากข้อมูลที่ถูกลบ มีการทดลองที่ดีในการกำหนดช่องว่างเหล่านั้นให้กับรายการใหม่เมื่อมีการเพิ่มหรือแย่กว่านั้นคือการสลับข้อมูลที่มีอยู่เพื่อให้ ID ใหม่เพื่อลบช่องว่าง แต่การทำเช่นนั้นจะทำให้เกิดปัญหาที่คุณต้องการ ไม่ต้องจัดการหากคุณทิ้งกุญแจไว้คนเดียว

สมมติว่าคุณกำลังเก็บฐานข้อมูลของเครื่องพิมพ์สำหรับจัดการเรียงลำดับวัสดุสิ้นเปลือง เครื่องพิมพ์ 13 เลเซอร์พรินเตอร์เก่าแยกย่อยจากการซ่อมเพื่อประหยัด ในขณะเดียวกันด้วยเหตุผลที่ไม่เกี่ยวข้องใครสั่งเครื่องพิมพ์ความร้อนใหม่สำหรับการพิมพ์บาร์โค้ดในคลังสินค้าและเครื่องพิมพ์ที่เกิดขึ้นก่อนที่จะมาแทนที่เครื่องพิมพ์ 13 ผู้ดูแลระบบบันทึกว่าเครื่องพิมพ์ใหม่ลงในฐานข้อมูลและเพราะตอนนี้ 13 ฟรี และคุณรีไซเคิล ID เครื่องพิมพ์ความร้อนเครื่องใหม่จะได้รับการจัดสรร 13 เป็น ID

ตอนนี้มีคนบอกคุณว่าเครื่องพิมพ์ 13 หมึกหมด คุณจำได้ว่าเครื่องพิมพ์ 13 เป็นเครื่องพิมพ์เลเซอร์ดังนั้นคุณจึงไม่ต้องกังวลกับการค้นหาในฐานข้อมูลและคุณสั่งซื้อตลับผงหมึก มีเพียงคุณเท่านั้นที่จำเป็นต้องสั่งชุดหมึกความร้อนเนื่องจากเครื่องพิมพ์ 13 ไม่ใช่เครื่องพิมพ์เลเซอร์อีกต่อไป เมื่อตลับผงหมึกมาถึงคุณไม่สามารถใช้งานได้เนื่องจากเป็นหมึกเติมที่ไม่ถูกต้องสำหรับเครื่องพิมพ์คุณไม่สามารถพิมพ์บาร์โค้ดได้อีกและคุณไม่สามารถจัดส่งคำสั่งซื้อใด ๆ ที่รอการส่งมอบได้

จะเกิดอะไรขึ้นถ้าคุณลบเครื่องพิมพ์ 13 และสลับเครื่องพิมพ์ทั้งหมดที่ลงมาเพื่อเติมเต็มช่องว่าง เครื่องพิมพ์ 14 (เมทริกซ์เก่าบางจุดเสื่อม) กลายเป็นเครื่องพิมพ์ 13, เครื่องพิมพ์ 15 กลายเป็นเครื่องพิมพ์ 14 และอื่น ๆ

เครื่องพิมพ์ทั้งหมดมีป้ายกำกับอยู่จึงสามารถอ้างอิงข้ามกับฐานข้อมูลได้ แต่ตอนนี้ป้ายกำกับทั้งหมดล้าสมัยแล้ว คุณจะต้องเดินไปรอบ ๆ ค้นหาเครื่องพิมพ์ทุกเครื่องในธุรกิจ (ซึ่งอาจมีหลายร้อย!) และติดฉลากใหม่ มันแทบจะไม่เป็นการใช้เวลาอย่างมีประสิทธิภาพ และมันก็เป็นกระบวนการที่เกิดข้อผิดพลาดได้ง่ายและจะเกิดอะไรขึ้นถ้ามันไม่เคยเกิดขึ้น? มีคนโทรเข้ามาเพื่อบอกว่าเครื่องพิมพ์ 14 มีปัญหาและจำเป็นต้องแก้ไขอย่างเร่งด่วนดังนั้นคุณจึงต้องค้นหาและพบว่าเครื่องพิมพ์ 14 เป็นเครื่องพิมพ์อิงค์เจ็ทในแผนกต้อนรับ เพียงเพราะคุณได้สับรหัสรอบ ๆ แล้วมันเป็นเครื่องพิมพ์ดอทเมทริกซ์ที่ต้องแก้ไขอย่างเร่งด่วน ผู้ชายที่โทรมาหาปัญหานั้นก็ถูกแขวนไว้ในขณะที่พนักงานต้อนรับมีคนคอยช่วยเหลือด้านเทคโนโลยีเธอไม่เคยเรียกร้องให้เปิดเครื่องเพื่อซ่อมเครื่องพิมพ์ซึ่งไม่เสีย

คุณควรคิดถึงรหัสที่กำหนดโดยระบบเพิ่มอัตโนมัติเป็นแบบถาวรมันไม่เปลี่ยนรูปและไม่สามารถนำกลับมาใช้ใหม่ได้แม้ว่าสิ่งที่ ID นั้นอ้างถึงจะสิ้นสุดลงแล้วก็ตาม บางคนอ้างว่าพวกเขาไม่ต้องการที่จะกังวลเกี่ยวกับ ID หมด แต่ถึงแม้จะมีระบบ 32 บิตและ ID ที่ลงนามแล้วก็ยังมี ID 2 พันล้านหรือมากกว่านั้น หากคุณสามารถทำให้คอลัมน์ ID ไม่ได้ลงนามได้นี่จะเพิ่มเป็น 4 พันล้านเท่าและบนระบบ 64 บิตจำนวนของรหัสที่มีอยู่นั้นมากกว่าจำนวนดวงดาวบนท้องฟ้าอย่างแท้จริง คุณจะไม่หมดรหัส

— GordonM
แหล่งที่มา

3

ในกรณีส่วนใหญ่คุณไม่ควรนึกถึงตัวเลขที่สร้างโดยอัตโนมัติเลยพวกเขาไม่มีความหมายและไม่ควรเปิดเผยต่อผู้ใช้ คุณไม่ควรได้รับข้อความแจ้งว่าเครื่องพิมพ์ 13 หมึกเหลือน้อยหรืออาจเป็น "เครื่องพิมพ์ในชุดที่ 13" แต่ไม่ใช่หมายเลขที่สร้างขึ้นอัตโนมัติ

— jmoreno

จริง แต่ตัวอย่างข้างต้นเป็นสิ่งที่ถูกต้องตัวอย่างเพื่อแสดงให้เห็นถึงสิ่งที่อาจผิดพลาดได้หากคุณทำสิ่งต่างๆด้วยกุญแจที่สร้างขึ้นโดยอัตโนมัติ ในความเป็นจริงแล้วการทำ Referential Integrity นั้นมีความสำคัญมากกว่ากัน

— GordonM

มันเป็นปัญหา RI เท่านั้นหากคุณไม่มีข้อ จำกัด ของรหัสต่างประเทศและมีรหัสต่างประเทศเป็น psuedo แทน ในกรณีนี้คุณอาจมีปัญหาใหญ่กว่า

— jmoreno

คุณจะประหลาดใจที่มีฐานข้อมูล mysql จำนวนมากที่ฉันยังพบอยู่นั่นเป็นแบบนั้น นักพัฒนาจำนวนมากดูเหมือนจะไม่ชอบ Innodb และแม้แต่ผู้ที่ไม่ได้ใช้สิ่งอำนวยความสะดวกทั้งหมด

— GordonM

4

คำตอบที่ดีมากมายอยู่ที่นี่แล้ว ฉันแค่ต้องการเพิ่มหนึ่งสถานการณ์ที่ยังไม่มีใครพูดถึง:

ข้อมูลที่สำคัญ หากผู้ใช้ลบออกคุณควรลบทิ้งจริงๆ!

สถานการณ์ที่พบบ่อยมากอย่างหนึ่งที่นึกถึงคือการเปลี่ยน / รีเซ็ตรหัสผ่าน คุณไม่ต้องการจัดเก็บรหัสผ่านเก่า (แม้ว่าพวกเขาจะถูกแฮชเค็ม ฯลฯ ) ในฐานข้อมูลของคุณ ผู้ใช้อาจใช้รหัสผ่านเก่า (และไม่ดี) ในเว็บไซต์อื่น ๆ

นอกจากนี้เมื่อพูดถึงกฎหมายเกี่ยวกับระยะเวลาที่คุณได้รับอนุญาตให้จัดเก็บข้อมูลบางประเภทแล้วแน่นอนว่าการลบแบบอ่อนจะไม่ทำ คุณต้องลบมันจริงๆ

ดังนั้นฉันจะถามตัวเอง: ผู้ใช้ (หรือคนอื่นเป็นรัฐบาล) จะบ้าถ้าฉันทำให้พวกเขาเชื่อว่าข้อมูลถูกลบ แต่ในความเป็นจริงฉันยังได้รับและสามารถกู้คืนได้ตลอดเวลา?

— จาคอบ
แหล่งที่มา

น่าสนใจ บริษัท ใหญ่ ๆ ใช้สิ่งนี้จริงหรือ?

— fuddin

2

นี่เป็นจุดที่ดี แต่สำหรับตัวอย่างประวัติรหัสผ่านของคุณคุณมักจะต้องการเก็บรหัสผ่านเก่าไว้เพื่อให้แน่ใจว่าพวกเขาจะไม่ซ้ำซ้อนกับรหัสผ่านใด ๆ ในช่วง 12 ปีที่ผ่านมาหรืออะไรก็ตาม อย่าเข้าใจฉันผิด - ฉันไม่ชอบนโยบายนี้ แต่ฉันใช้งานไปแล้วและดูเหมือนว่าเป็นเรื่องธรรมดาในแอปสำหรับองค์กร

— Mike Partridge

2

เพียงแค่พูดจาอวดรู้คุณไม่ควรเก็บรหัสผ่านไว้ที่ไหน คุณเก็บผลลัพธ์ที่เข้ารหัส (ทางเดียว) หากมีคนลืมรหัสผ่านของพวกเขาคุณสร้างใหม่สำหรับพวกเขา ไม่ควรมีวิธี "กู้คืน" รหัสผ่านเพราะถ้าคุณทำได้รหัสผ่านก็จะมีคนอื่นได้

— TMN

1

หมายเลขบัตรเครดิต ไม่ควรเก็บไว้ ที่จริงจะต้องไม่ถูกจัดเก็บ หากลูกค้าโง่พอที่จะส่งหมายเลขบัตรเครดิตของพวกเขาในอีเมลฉันมีปัญหาจริง จะต้องมีวิธีในการกำจัดมัน

— gnasher729

GDP ของสหภาพยุโรปส่งความนับถือ

— displayname

3

โดยทั่วไปฉันจะไม่ลบข้อมูลผู้ใช้ในฐานข้อมูลของฉัน ฉันตั้งค่าสถานะให้ซ่อน บ่อยครั้งที่ผู้ใช้ลบบางสิ่งโดยไม่ตั้งใจและต้องการเปลี่ยนได้อย่างง่ายดาย นอกจากนี้ยังช่วยรักษาความสมบูรณ์ของการอ้างอิงสำหรับข้อมูลที่เกี่ยวข้อง ใช้งานได้กับฐานข้อมูลขนาดเล็กถึงปานกลาง ในระบบที่ประสิทธิภาพได้รับผลกระทบอย่างมากจากการตัดสินใจนี้มีการจัดการในรูปแบบพิเศษเช่นตารางเก็บถาวรการสำรองข้อมูลอัตโนมัติเป็นต้น

เราจะทิ้งข้อมูลแบ็คเอนด์ตามความจำเป็นเช่นข้อมูลเซสชั่นเว็บไซต์หมดอายุและข้อมูลบันทึกเก่า ไม่มีประเด็นที่จะทำให้พวกเขาตลอดไป

แม้ว่าตามปกติแล้วคำตอบที่แท้จริงนั้นขึ้นอยู่กับสถานการณ์เฉพาะ

— แมตต์เอส
แหล่งที่มา

1

ฉันทำงานกับแอปพลิเคชันแลกเปลี่ยนเงินตราต่างประเทศมาสองสามปีแล้ว ข้อมูลที่แอปพลิเคชันที่รวบรวมในช่วงหลายปีที่ผ่านมามีผลกระทบต่อประสิทธิภาพการทำงาน (พูดแบบ exponentional)

หลังจากที่เราได้ทำสิ่งที่เราสามารถทำได้ในแง่ของรหัสเราเสนอให้จัดการเพื่อเก็บข้อมูลเก่ากว่าปี พวกเขาตรวจสอบแนวคิด (ปัญหาทางกฎหมาย) และโชคดีที่เราสามารถทำได้ ดังนั้นเราจึงลบ แต่เราก็เก็บข้อมูลเพื่อให้ธุรกิจยังสามารถเรียกใช้รายงานของพวกเขาได้

— dbalakirev
แหล่งที่มา

1

ในกรณีส่วนใหญ่คุณควรเก็บข้อมูลในกรณีที่จำเป็นในอนาคต ธุรกิจที่คุณทำงานอาจต้องการดูข้อมูลในอดีตเพื่อยึดการตัดสินใจของพวกเขาซึ่งจะนำพา บริษัท ไปในทิศทางที่แน่นอน

คุณควรเพิ่มคอลัมน์ 'Date_Time_Removed' ลงในแต่ละตารางแล้วแทนที่การลบแถวที่คุณตั้งค่าวันที่และเวลาที่แถวนั้นถูกลบไปจริง จากนั้นในกระบวนงานที่เก็บไว้หรือ sql ของคุณคุณจะคำนึงถึงในคอลัมน์ 'Date_Time_Removed' เช่นเลือก blah จาก table1 โดยที่ date_time_removed เป็นโมฆะ

แถวของหลักสูตรที่ถูกเพิ่มไปยังฐานข้อมูลโดยไม่ตั้งใจควรถูกลบอย่างถาวรโดยเฉพาะข้อมูลทดสอบ

โดยการเก็บรักษาข้อมูลที่ถูกต้องทั้งหมดคุณต้องเลือกใช้ฐานข้อมูลของคุณสำหรับการจัดเก็บในอนาคต

— Julian Mummery
แหล่งที่มา

0

สถานการณ์อื่นที่ไม่ใช่สถานการณ์อื่นที่นำเสนอคือเมื่อข้อมูลถูกลบ แต่บันทึกการดำเนินการที่ทำในฐานข้อมูล (รวมถึงการลบ) จะถูกเก็บไว้ในที่เก็บถาวรเป็นเวลานาน ขอบเขตหลักของสิ่งนี้คือการนำระบบย้อนกลับไปใช้กับวันที่ผ่านมา แต่ก็สามารถใช้เพื่อจัดเก็บข้อมูลที่ถูกลบในบางวิธี (ซึ่งถูกลบออกจากฐานข้อมูล แต่เก็บไว้ในคลังเก็บ)

การจัดเก็บข้อมูลที่ถูกลบจะไม่เป็นเรื่องใหญ่ บริษัท ขนาดใหญ่อาจเก็บรหัสรุ่นและข้อมูลอื่น ๆ อีกมากมาย (ไม่ต้องพูดถึงสิ่งที่ไม่เกี่ยวข้องกับด้านเทคนิค) ดังนั้นในที่สุดการจัดเก็บข้อมูลขนาดใหญ่ก็เป็นเรื่องปกติสำหรับพวกเขา

— แนวปะการัง
แหล่งที่มา