วิธีปฏิบัติที่ดีที่สุดสำหรับการจัดเก็บข้อมูลเมตาของระเบียน

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

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

1. เก็บข้อมูลเมตาโดยตรงในตาราง

   ข้อดี:

   • ข้อมูล Meta เชื่อมโยงโดยตรงกับบันทึก
   • ไม่จำเป็นต้องใช้ตัวเชื่อมเพื่อดึงข้อมูลเมตา

   จุดด้อย:

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

2. สร้างตารางข้อมูลเมตาทั่วไปด้วยและใช้ซอฟต์คีย์ต่างประเทศเพื่อลิงค์ข้อมูลไปยังตารางและเรกคอร์ดที่ถูกต้อง

   ข้อดี:

   • ไม่มีการทำซ้ำคอลัมน์
   • ข้อมูล Meta ถูกแยกออกจากข้อมูลธุรกิจ

   จุดด้อย:

   • ไม่มีลิงก์โดยตรงระหว่างข้อมูลเมตาและข้อมูล (ไม่สามารถใช้ FK ได้)
   • เข้าร่วมต้องมีเงื่อนไขเพิ่มเติม

3. สร้างตารางข้อมูลเมตาแต่ละตารางสำหรับแต่ละตารางที่ต้องการข้อมูลเมตา

   ข้อดี:

   • ข้อมูล Meta เชื่อมโยงโดยตรงกับบันทึก
   • ข้อมูล Meta ถูกแยกออกจากข้อมูลธุรกิจ

   จุดด้อย:

   • ต้องใช้ตารางเสริมจำนวนมาก
   • จำเป็นต้องใช้คอลัมน์ที่ซ้ำกันจำนวนมาก (เว้นแต่จะใช้การสืบทอด)

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

คอลัมน์ที่คุณกำลังพูดถึงมีขนาด 20 ไบต์ (หากจัดชิดโดยไม่มีการเว้นช่องว่าง):

เวลาการสร้างเวลาอัปเดตและแหล่งที่สร้าง

การประทับเวลา .. 8 ไบต์การ
ประทับเวลา ..
จำนวนเต็ม8 ไบต์.. 4 ไบต์

ส่วนหัว tuple และตัวชี้รายการสำหรับแถวที่แยกจากกันในตารางแยกต่างหากอย่างเดียวจะใช้ 23 + 1 + 4 = 28 ไบต์บวกกับข้อมูลจริง 20 ไบต์รวมทั้งเพิ่มช่องว่างภายใน 4 ไบต์ ทำให้52 ไบต์ต่อแถว อ่านเพิ่มเติมได้ที่นี่:

• การกำหนดค่า PostgreSQL สำหรับประสิทธิภาพการอ่าน

เกี่ยวกับพื้นที่เก็บข้อมูลคุณไม่มีอะไรจะได้รับ ประสิทธิภาพที่เกี่ยวข้องกับการที่คุณสูญเสียสิ่งใดไปเพียง 16 - 24 ไบต์ต่อแถว

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

นอกจากนี้ยังง่ายต่อการเขียน a TRIGGER ON INSERT OR UPDATEเพื่อให้เป็นปัจจุบัน

เรื่องยาวสั้น: การลงคะแนนเสียงที่แข็งแกร่งสำหรับคุณตัวเลือกที่ 1

ฉันจะไปที่ตัวเลือกที่ 3 :
หากมีการปรับปรุงข้อมูลเมตาบ่อยในขณะที่แถวหลักไม่ จากนั้นอาจจ่ายเพื่อแยกตาราง 1: 1 เพื่อทำให้การอัปเดตราคาถูกลงและลดการขยายตัวของตารางหลัก - หรือแม้แต่ไปที่ตัวเลือก 2

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