การออกแบบที่ดีที่สุดสำหรับตารางฐานข้อมูลการเปลี่ยนแปลง / การตรวจสอบ? [ปิด]

ฉันต้องการสร้างตารางฐานข้อมูลเพื่อจัดเก็บบันทึกการเปลี่ยนแปลง / การตรวจสอบต่างๆ (เมื่อมีการเพิ่มลบแก้ไข ฯลฯ ) ฉันไม่จำเป็นต้องเก็บข้อมูลรายละเอียดโดยเฉพาะดังนั้นฉันจึงคิดบางอย่างตามแนวของ:

• id (สำหรับเหตุการณ์)
• ผู้ใช้ที่เรียกใช้
• ชื่อเหตุการณ์
• คำอธิบายเหตุการณ์
• การประทับเวลาของเหตุการณ์

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

ในโครงการที่ฉันกำลังดำเนินการบันทึกการตรวจสอบยังเริ่มต้นจากการออกแบบที่เรียบง่ายเช่นที่คุณอธิบายไว้:

event ID
event date/time
event type
user ID
description

ความคิดเหมือนกัน: เพื่อให้สิ่งต่างๆเรียบง่าย

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

Who the heck created/updated/deleted a record 
with ID=X in the table Foo and when?

ดังนั้นเพื่อให้สามารถตอบคำถามดังกล่าวได้อย่างรวดเร็ว (โดยใช้ SQL) เราจึงมีคอลัมน์เพิ่มเติมอีกสองคอลัมน์ในตารางการตรวจสอบ

object type (or table name)
object ID

นั่นคือตอนที่การออกแบบบันทึกการตรวจสอบของเรามีความเสถียร (เป็นเวลาไม่กี่ปีแล้ว)

แน่นอนว่า "การปรับปรุง" ครั้งสุดท้ายจะใช้ได้กับตารางที่มีคีย์ตัวแทนเท่านั้น แต่เดาอะไร? ตารางทั้งหมดของเราที่ควรค่าแก่การตรวจสอบมีกุญแจสำคัญ!

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

ในขณะที่คุณออกแบบคุณควรเขียนโค้ดเพื่อกู้คืนข้อมูล เมื่อคุณจำเป็นต้องฟื้นตัวมักจะรีบควรเตรียมตัวให้พร้อม

มีหลายสิ่งที่คุณอาจต้องการตรวจสอบเช่นชื่อตาราง / คอลัมน์คอมพิวเตอร์ / แอปพลิเคชันที่ใช้อัปเดตและอื่น ๆ

ตอนนี้ขึ้นอยู่กับว่าคุณต้องการการตรวจสอบโดยละเอียดเพียงใดและในระดับใด

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

เคล็ดลับ:

• รวมค่าก่อน / หลัง

• รวม 3-4 คอลัมน์สำหรับจัดเก็บคีย์หลัก (ในกรณีที่เป็นคีย์ผสม)

• จัดเก็บข้อมูลนอกฐานข้อมูลหลักตามที่โรเบิร์ตแนะนำแล้ว

• ใช้เวลาอย่างเหมาะสมในการจัดเตรียมรายงานโดยเฉพาะอย่างยิ่งที่คุณอาจต้องใช้ในการกู้คืน

• แผนการจัดเก็บชื่อโฮสต์ / แอปพลิเคชัน - สิ่งนี้อาจมีประโยชน์มากสำหรับการติดตามกิจกรรมที่น่าสงสัย

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

1. ใส่ตารางการตรวจสอบของคุณในฐานข้อมูลอื่น ตามหลักการแล้วคุณต้องการแยกออกจากข้อมูลเดิม หากคุณต้องการกู้คืนฐานข้อมูลคุณไม่ต้องการกู้คืนเส้นทางการตรวจสอบ

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

สิ่งที่เรามีในตารางของเรา: -

Primary Key
Event type (e.g. "UPDATED", "APPROVED")
Description ("Frisbar was added to blong")
User Id
User Id of second authoriser
Amount
Date/time
Generic Id
Table Name

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

ในการตรวจสอบแบบกำหนดเองทั่วไป (การสร้างตารางต่างๆ) เป็นตัวเลือกที่ไม่ดี ทริกเกอร์ฐานข้อมูล / ตารางสามารถปิดใช้งานเพื่อข้ามกิจกรรมบันทึกบางอย่างได้ ตารางการตรวจสอบที่กำหนดเองสามารถแก้ไขได้ อาจมีข้อยกเว้นที่จะนำไปใช้ ไม่กล่าวถึงปัญหาในการออกแบบโซลูชันที่มีประสิทธิภาพ จนถึงตอนนี้ฉันเห็นกรณีง่ายๆในการสนทนานี้ คุณต้องแยกออกจากฐานข้อมูลปัจจุบันและจากผู้ใช้ที่มีสิทธิ์ (DBA, Developers) RDBMS กระแสหลักทุกตัวมีสิ่งอำนวยความสะดวกในการตรวจสอบที่แม้แต่ DBA ก็ไม่สามารถปิดใช้งานการปลอมแปลงเป็นความลับ ดังนั้นความสามารถในการตรวจสอบที่ระบุโดยผู้ขาย RDBMS จะต้องเป็นตัวเลือกแรก ตัวเลือกอื่น ๆ จะเป็นโปรแกรมอ่านบันทึกธุรกรรมของบุคคลที่สามหรือโปรแกรมอ่านบันทึกที่กำหนดเองซึ่งจะผลักดันข้อมูลที่ถูกย่อยสลายไปยังระบบการส่งข้อความที่ลงท้ายด้วยรูปแบบของการตรวจสอบคลังข้อมูลหรือตัวจัดการเหตุการณ์แบบเรียลไทม์ สรุป: Solution Architect / "Hands on Data Architect" จำเป็นต้องมีส่วนร่วมในการกำหนดระบบดังกล่าวตามข้อกำหนด โดยปกติแล้วจะเป็นเรื่องที่ร้ายแรงเกินกว่าที่จะส่งมอบให้กับนักพัฒนาเพื่อแก้ไขปัญหา

มีหลายวิธีในการทำเช่นนี้ วิธีที่ฉันชอบคือ:

1. เพิ่มmod_userเขตข้อมูลในตารางต้นทางของคุณ (ช่องที่คุณต้องการบันทึก)

2. สร้างตารางบันทึกที่มีเขตข้อมูลที่คุณต้องการบันทึกรวมทั้งเขตข้อมูล log_datetimeและ เป็นคีย์หลักseq_numseq_num

3. สร้างทริกเกอร์บนตารางต้นทางที่แทรกระเบียนปัจจุบันลงในตารางบันทึกเมื่อใดก็ตามที่มีการเปลี่ยนแปลงฟิลด์ที่ถูกตรวจสอบ

ตอนนี้คุณมีบันทึกการเปลี่ยนแปลงทุกอย่างและใครเป็นคนทำ

ตามหลักการแยก:

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

2. อย่าใช้ทริกเกอร์ในการตรวจสอบฐานข้อมูลทั้งหมดเพราะคุณจะต้องใช้ฐานข้อมูลที่แตกต่างกันเพื่อรองรับ คุณจะต้องเขียนหนึ่งสำหรับ DB2, SQLServer, Mysql และอื่น ๆ