จัดการผู้ใช้ที่ถูกลบ - ตารางแยกหรือเดียวกัน

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

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

สิ่งที่ฉันได้สังเกตเห็นว่าทั่วทั้งระบบของเราตามปกติของสิ่งที่เราอย่างต่อเนื่องสอบถามตารางการตรวจสอบผู้ใช้ผู้ใช้จะไม่ถูกลบในขณะที่สิ่งที่ฉันคิดคือการที่เราไม่จำเป็นต้องทำอย่างนั้นเลย ... ! [ชี้แจง 1: โดย 'ค้นหาอย่างต่อเนื่อง' ฉันหมายถึงเรามีข้อความค้นหาที่เป็นเช่น: '... จากผู้ใช้ WHERE isdeleted = "0" AND ... ' ตัวอย่างเช่นเราอาจต้องดึงข้อมูลผู้ใช้ทั้งหมดที่ลงทะเบียนสำหรับการประชุมทั้งหมดในวันที่ระบุดังนั้นในการค้นหานั้นเรายังมีผู้ใช้จากที่ไหน WHERE isdeleted = "0" - สิ่งนี้ทำให้ประเด็นของฉันชัดเจนขึ้นหรือไม่]

(1) continue keeping deleted users in the 'main' users table
(2) keep deleted users in a separate table (mostly required for historical
    book-keeping)

อะไรคือข้อดีข้อเสียของวิธีการอย่างใดอย่างหนึ่ง?

(1) ให้ผู้ใช้ที่ถูกลบยังคงอยู่ในตารางผู้ใช้ 'หลัก'

• ข้อดี: การค้นหาที่ง่ายขึ้นในทุกกรณี
• ข้อด้อย: อาจลดประสิทธิภาพเมื่อเวลาผ่านไปหากมีผู้ใช้จำนวนมาก

(2) ให้ผู้ใช้ที่ถูกลบอยู่ในตารางแยกต่างหาก (ส่วนใหญ่จำเป็นสำหรับการเก็บรักษาประวัติ)

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

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

ฉันขอแนะนำให้ใช้ตารางเดียวกัน เหตุผลหลักคือความถูกต้องของข้อมูล เป็นไปได้ว่าจะมีหลายตารางที่มีความสัมพันธ์ขึ้นอยู่กับผู้ใช้ เมื่อผู้ใช้ถูกลบคุณไม่ต้องการออกจากบันทึกเหล่านั้นกำพร้า
การมีประวัติเด็กกำพร้าทำให้การบังคับใช้ข้อ จำกัด นั้นยากขึ้นและทำให้ยากต่อการค้นหาข้อมูลทางประวัติศาสตร์ พฤติกรรมอื่น ๆ ที่ควรพิจารณาเมื่อผู้ใช้ส่งอีเมล์ที่ใช้ถ้าคุณต้องการให้พวกเขากู้คืนบันทึกเก่าทั้งหมดของพวกเขา สิ่งนี้จะทำงานโดยอัตโนมัติโดยใช้การลบแบบอ่อน เท่าที่มีการเข้ารหัสไว้ตัวอย่างเช่นในแอปพลิเคชัน c # linq ปัจจุบันของฉันคำสั่งที่ลบ = 0 จะถูกต่อท้ายโดยอัตโนมัติในตอนท้ายของการค้นหาทั้งหมด

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

มันทำให้ฉันมีกลิ่นเหม็นของการออกแบบ คุณควรซ่อนตรรกะแบบนี้ ตัวอย่างเช่นคุณควรมีUserServiceวิธีการisValidUser(userId)ใช้ "ข้ามระบบของคุณ" แทนที่จะทำสิ่งที่ชอบ:

"รับบันทึกผู้ใช้ตรวจสอบว่าผู้ใช้ตั้งค่าสถานะเป็นลบหรือไม่"

วิธีการจัดเก็บผู้ใช้ที่ถูกลบของคุณไม่ควรส่งผลกระทบต่อตรรกะทางธุรกิจ

ด้วยการห่อหุ้มแบบนี้อาร์กิวเมนต์ข้างต้นไม่ควรส่งผลต่อวิธีการคงอยู่ของคุณอีกต่อไป จากนั้นคุณสามารถมุ่งเน้นไปที่ข้อดีและข้อเสียที่เกี่ยวข้องกับการติดตาตัวเอง

สิ่งที่ต้องพิจารณารวมถึง:

• บันทึกที่ถูกลบควรจะถูกลบทิ้งไปนานแค่ไหน?
• สัดส่วนของบันทึกที่ถูกลบคืออะไร?
• จะมีปัญหาสำหรับ Referential Integrity หรือไม่ (เช่นผู้ใช้ถูกอ้างอิงจากตารางอื่น) หากคุณลบออกจากตารางจริง
• คุณพิจารณาเปิดผู้ใช้อีกครั้งหรือไม่

ปกติฉันจะใช้วิธีรวม:

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

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

เพื่อที่จะตอบว่าคำถามที่คุณต้องตอบคำถามอื่น ๆ : ทำไมจะบันทึกถูกลบ?

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

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

นอกจากนี้ยังมีสาเหตุที่น่าสงสารสำหรับการลบอย่างหนัก (เพิ่มเติมเกี่ยวกับเหตุผลเหล่านี้ในภายหลัง):

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

ทำไมคุณถามว่ามันเป็นเรื่องใหญ่จริงเหรอ? เกิดอะไรขึ้นกับ ole ที่ดี ' DELETE?

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

ดังนั้นการลบแบบอ่อนจะดีกว่าใช่ไหม ไม่ไม่:

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

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

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

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

• ลูกค้าสร้างบัญชี
• ลูกค้ายกเลิกบัญชี
• ลูกค้าต่ออายุบัญชี
• ลูกค้ายกเลิกบัญชี
• ...

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

+-----------+       +-------------+       +-----------------+
| Account   | --->* | Agreement   | --->* | AgreementStatus |
+-----------+       +-------------+       +----------------+
| Id        |       | Id          |       | AgreementId     |
| Name      |       | AccountId   |       | EffectiveDate   |
| Email     |       | ...         |       | StatusCode      |
+-----------+       +-------------+       +-----------------+

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

หากความต้องการในแอปพลิเคชันของคุณบ่อยครั้งคือการรับรายการข้อตกลง / บัญชีที่ใช้งานอยู่มันเป็นคำถามที่ยุ่งยากเล็กน้อย

CREATE VIEW ActiveAgreements AS
SELECT agg.Id, agg.AccountId, acc.Name, acc.Email, s.EffectiveDate, ...
FROM AgreementStatus s
INNER JOIN Agreement agg
    ON agg.Id = s.AgreementId
INNER JOIN Account acc
    ON acc.Id = agg.AccountId
WHERE s.StatusCode = 'ACTIVE'
AND NOT EXISTS
(
    SELECT 1
    FROM AgreementStatus so
    WHERE so.AgreementId = s.AgreementId
    AND so.EffectiveDate > s.EffectiveDate
)

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

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

ปัญหาเดียวที่จะแก้ไขคือปัญหาประสิทธิภาพการทำงาน ในหลายกรณีมันกลายเป็นเรื่องที่ไม่เป็นปัญหาเพราะมีการทำดัชนีคลัสเตอร์AgreementStatus (AgreementId, EffectiveDate)- มี I / O น้อยมากที่กำลังค้นหาที่นั่น แต่ถ้าเป็นปัญหาก็มีวิธีแก้ไขโดยใช้ทริกเกอร์มุมมองที่จัดทำดัชนี / เป็นรูปเป็นร่างเหตุการณ์ระดับแอปพลิเคชัน ฯลฯ

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

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

ดังนั้นฉันขอแนะนำตารางประวัติแยกต่างหาก

การแบ่งโต๊ะออกเป็นสองส่วนจะเป็นสิ่งที่เกินความคาดหมาย

นี่คือสองขั้นตอนง่าย ๆ ที่ฉันอยากจะแนะนำ:

1. เปลี่ยนชื่อตาราง 'users' เป็น 'allusers'
2. สร้างมุมมองที่เรียกว่า 'users' เป็น 'select * จาก allusers ที่ delete = false'

ป.ล. ขออภัยสำหรับความล่าช้าในการตอบรับเป็นเวลาหลายเดือน!

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

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

คุณไม่ได้กล่าวถึงการใช้งาน DBMS หากคุณมี Oracle พร้อมสิทธิ์การใช้งานที่เหมาะสมคุณสามารถพิจารณาการแบ่งพาร์ติชันตารางผู้ใช้ออกเป็นสองพาร์ติชัน: ผู้ใช้ที่ใช้งานและถูกลบ