แนวปฏิบัติที่เหมาะสมที่สุดสำหรับการเลิกใช้คอลัมน์ฐานข้อมูลล้าสมัยคืออะไร [ปิด]

ฉันออกแบบแอปพลิเคชันซึ่งจะรวบรวมข้อมูล A, B และ C จากลูกค้าในระยะแรก แต่หลังจากนั้นจะรวบรวมข้อมูล A, B และ D แทน

A, B, C และ D ที่เกี่ยวข้องมากและในขณะนี้มีอยู่เป็นคอลัมน์ของฐานข้อมูลเดียว PostgreSQL ตารางT

เมื่อไม่ต้องการใช้ C อีกต่อไปฉันต้องการลบการอ้างอิงออกจากแอปพลิเคชันของฉัน (ฉันใช้Django ORM ) แต่ฉันต้องการเก็บข้อมูลที่ป้อนไว้แล้ว วิธีที่ดีที่สุดที่จะทำคืออะไร?

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

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

มีตัวเลือกที่ดีกว่าที่ฉันไม่เห็นหรือไม่

รายละเอียดพิเศษบางอย่าง:

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

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

ตกลงดังนั้นสถานการณ์ของคุณคือคุณต้องการให้แถวเก่ามีคุณสมบัติ 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

ดังนั้นคุณสามารถสร้างสคริปต์การย้ายข้อมูลเพื่อสร้างตาราง Old ใหม่คัดลอกข้อมูล id และ C ไปยังมันและลบคอลัมน์ C ออกจากตาราง All

อัปเดตรหัสของคุณตามต้องการด้วย sql ใหม่

หรือหากคุณต้องการสืบค้นข้อมูล C เก่าคุณสามารถสร้างตารางเก็บถาวรใหม่ด้วย A, B, C คัดลอกข้อมูลทั้งหมดและลบคอลัมน์ C เพิ่มคอลัมน์ D ลงในตาราง 'สด' ของคุณ

หากการจัดเก็บข้อมูลอาจเป็นปัญหาให้แบ่งตาราง: คีย์ / A / B คีย์ / C คีย์ / D

คุณสามารถทำการเข้าถึงได้ผ่านทางมุมมอง (คำจำกัดความของตำแหน่งข้อมูลในฐานข้อมูล) หรือผ่านการเปลี่ยนคำจำกัดความ ORM

นี่ไม่ใช่นักแสดงที่มีประสิทธิภาพมากที่สุด (มีส่วนร่วมในการเข้าร่วม) แต่มันสามารถนำเสนอการรวมกันของ A / B / C / D เมื่อเวลาผ่านไปโดยไม่ต้องเปลี่ยนที่เก็บข้อมูลพื้นฐาน & ขึ้นอยู่กับรูปแบบการเข้าถึงจริงของคุณ

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

การเข้าถึงผ่านมุมมองช่วยให้คุณสามารถเปลี่ยนจาก A / B / C เป็น A / B / C / D เป็น A / B / D ในตารางต้นแบบที่มีการเปลี่ยนแปลงน้อยที่สุดและไม่มีการเคลื่อนไหวของข้อมูล มุมมองจะโปร่งใสกับตรรกะการอ่านและถ้า dbms ของคุณรองรับทั้งฟังก์ชั่นหรือมุมมองที่อัพเดตได้แล้วก็โปร่งใสกับตรรกะการเขียนเช่นกัน

ฉันคิดว่าการตัดสินใจของคุณจะสะท้อนข้อกังวลมากมายในโลกแห่งความเป็นจริง: 1) ประเภทข้อมูล C & D 2) ปริมาณข้อมูลสัมพัทธ์ที่รวบรวมไว้สำหรับ C / D 3) การทับซ้อนของ C / D เทียบกับรายการ C หรือ D ล้วนๆ 4) ความพร้อมใช้งานของหน้าต่างดาวน์ไทม์ / การบำรุงรักษาและระยะเวลา 5) การสนับสนุน DBMS สำหรับมุมมองที่อัปเดต 6) ความต้องการในการเก็บรายละเอียดโครงสร้างทางกายภาพของฐานข้อมูลใน ORM เทียบกับทำให้โปร่งใสโดยการนำเสนอผ่านมุมมอง / ฟังก์ชั่นในฐานข้อมูล แอปพลิเคชันไม่ใช่เฉพาะแอปพลิเคชันปัจจุบัน)

คำตอบของฉันเป็นที่ต้องการสำหรับประเภทข้อมูลขนาดใหญ่ / ซับซ้อนสำหรับ (1) ทับซ้อนเล็กน้อยสำหรับ (3) และหยุดทำงานน้อยที่สุดสำหรับ (4) โดยมีการสนับสนุน dbms ที่ดีใน (5) และแอปพลิเคชันหลายตัวที่เข้าถึงข้อมูลใน (6)

แต่ไม่มีทางที่ถูก / ผิดสำหรับทางเลือกมากมาย: - เริ่มต้นด้วย A / B / C, ต่อมาเพิ่ม D, ปรับ ORM, ยังคงวางคอลัมน์ C ในภายหลัง - เริ่มต้นด้วย A / B / C / D และละเว้น nulls เป็นต้น พิจารณาโซลูชันของคุณและสิ่งที่คุณรู้เกี่ยวกับวัตถุประสงค์ / วงจรชีวิตที่กำหนดไว้ทำแบบจำลองขนาด / ปริมาณและคาดว่าจะเปลี่ยนแปลงสิ่งต่าง ๆ ในภายหลัง

การลบการอ้างอิง & การย้ายข้อมูลเป็นตัวเลือกที่มีความเสี่ยงต่ำ

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

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

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

มีหลายสิ่งที่ต้องพิจารณาที่นี่ แต่คุณอาจต้องการพิจารณาเพิ่มมุมมองเพื่อวางซ้อนตารางแทนที่จะทำการเปลี่ยนแปลงกับตารางโดยตรง ด้วยวิธีนี้มันเป็นเพียงมุมมองที่จำเป็นต้องเปลี่ยน

ฉันไม่รู้จัก Django ORM แต่อาจเป็นไปได้

• คุณมีตาราง A ที่มีคอลัมน์ a, b, c
• สร้างตาราง B ใหม่พร้อมคอลัมน์ a, b, d
• ย้ายข้อมูลของคุณไปที่ตาราง B
• ย้ายกุญแจต่างประเทศของคุณไปที่ตาราง A ถึงตาราง B

ตอนนี้คุณสามารถใช้ตาราง B และคุณยังมีข้อมูลเก่าของคุณสำหรับการอ้างอิง