أفضل تصميم لجدول قاعدة بيانات التغيير/التدقيق؟[مغلق]

Question

أحتاج إلى إنشاء جدول قاعدة بيانات لتخزين سجل/تدقيق تغيير مختلف (عند إضافة شيء ما ، وحذفه ، وتعديله ، وما إلى ذلك).لا أحتاج إلى تخزين معلومات مفصلة بشكل خاص، لذلك كنت أفكر في شيء على غرار ما يلي:

• معرف (للحدث)
• المستخدم الذي أثار ذلك
• اسم الحدث
• وصف الحدث
• الطابع الزمني للحدث

نسيت شيئا ما هنا؟من الواضح أنه يمكنني الاستمرار في تحسين التصميم، على الرغم من أنني لا أخطط لجعله معقدًا (إنشاء جداول أخرى لأنواع الأحداث أو أشياء من هذا القبيل أمر غير وارد لأنه يمثل تعقيدًا لاحتياجاتي).

Answer 1

في المشروع الذي أعمل عليه، بدأ سجل التدقيق أيضًا من التصميم البسيط للغاية، مثل التصميم الذي وصفته:

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

وذلك عندما استقر تصميم سجل التدقيق لدينا بالفعل (لبضع سنوات حتى الآن).

وبطبيعة الحال، فإن "التحسين" الأخير سيعمل فقط مع الجداول التي تحتوي على مفاتيح بديلة.لكن خمن ماذا؟جميع جداولنا التي تستحق التدقيق تحتوي على مثل هذا المفتاح!

Answer 2

هناك العديد من الأشياء الأخرى التي قد ترغب في تدقيقها، مثل أسماء الجداول/الأعمدة، والكمبيوتر/التطبيق الذي تم إجراء التحديث منه، والمزيد.

الآن، يعتمد هذا على مدى حاجتك للتدقيق التفصيلي وعلى أي مستوى.

لقد بدأنا في إنشاء حل التدقيق القائم على التشغيل الخاص بنا، وأردنا تدقيق كل شيء ولدينا أيضًا خيار الاسترداد في متناول اليد.تبين أن هذا الأمر معقد للغاية، لذلك انتهى بنا الأمر إلى إجراء هندسة عكسية لأداة الطرف الثالث القائمة على المشغل تدقيق ApexSQL لإنشاء الحل المخصص الخاص بنا.

نصائح:

• تضمين القيم قبل/بعد

• قم بتضمين 3-4 أعمدة لتخزين المفتاح الأساسي (في حالة أنه مفتاح مركب)

• قم بتخزين البيانات خارج قاعدة البيانات الرئيسية كما اقترح روبرت بالفعل

• اقض قدرًا لا بأس به من الوقت في إعداد التقارير، خاصة تلك التي قد تحتاجها للتعافي

• خطط لتخزين اسم المضيف/التطبيق - قد يكون هذا مفيدًا جدًا لتتبع الأنشطة المشبوهة

Answer 3

نقوم أيضًا بتسجيل القيم القديمة والجديدة والعمود الذي تنتمي إليه بالإضافة إلى المفتاح الأساسي للجدول الذي يتم تدقيقه في جدول تفاصيل التدقيق.فكر في ما تحتاجه لجدول التدقيق؟لا تريد فقط معرفة من قام بالتغيير ومتى، ولكن عندما يحدث تغيير سيء، فأنت تريد طريقة سريعة لإعادة البيانات مرة أخرى.

أثناء قيامك بالتصميم، يجب عليك كتابة التعليمات البرمجية لاستعادة البيانات.عندما تحتاج إلى التعافي، فعادةً ما تكون في عجلة من أمرك، ومن الأفضل أن تكون مستعدًا بالفعل.

Answer 4

هناك الكثير من الإجابات المثيرة للاهتمام هنا وفي أسئلة مماثلة.الأشياء الوحيدة التي يمكنني إضافتها من تجربتي الشخصية هي:

1. ضع جدول التدقيق الخاص بك في قاعدة بيانات أخرى.من الناحية المثالية، تريد الانفصال عن البيانات الأصلية.إذا كنت بحاجة إلى استعادة قاعدة البيانات الخاصة بك، فأنت لا تريد حقًا استعادة مسار التدقيق.

2. إزالة التطبيع قدر الإمكان.تريد أن يحتوي الجدول على أقل عدد ممكن من التبعيات للبيانات الأصلية.يجب أن يكون جدول التدقيق بسيطًا وسريعًا للغاية لاسترداد البيانات منه.لا توجد عمليات انضمام أو بحث رائعة عبر الجداول الأخرى للوصول إلى البيانات.

Answer 5

ماذا لدينا في طاولتنا:-

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

يشير المعرف العام إلى صف في الجدول الذي تم تحديثه واسم الجدول هو اسم هذا الجدول كسلسلة.ليس تصميمًا جيدًا لقاعدة البيانات، ولكنه قابل للاستخدام للغاية.تحتوي جميع جداولنا على عمود مفتاح بديل واحد، لذا يعمل هذا بشكل جيد.

Answer 6

هناك طرق عديدة للقيام بذلك.طريقتي المفضلة هي:

1. أضف mod_user الحقل إلى الجدول المصدر الخاص بك (الجدول الذي تريد تسجيله).

2. قم بإنشاء جدول سجل يحتوي على الحقول التي تريد تسجيلها، بالإضافة إلى أ log_datetime و seq_num مجال. seq_num هو المفتاح الأساسي.

3. قم بإنشاء مشغل على الجدول المصدر يقوم بإدراج السجل الحالي في جدول السجل كلما تم تغيير أي حقل مراقب.

الآن لديك سجل بكل تغيير ومن قام به.

Answer 7

بشكل عام، يعد التدقيق المخصص (إنشاء جداول مختلفة) خيارًا سيئًا.يمكن تعطيل مشغلات قاعدة البيانات/الجدول لتخطي بعض أنشطة السجل.يمكن التلاعب بجداول التدقيق المخصصة.يمكن أن تحدث استثناءات من شأنها إسقاط التطبيق.ناهيك عن الصعوبات في تصميم حل قوي.حتى الآن أرى حالات بسيطة جدًا في هذه المناقشة.أنت بحاجة إلى الانفصال الكامل عن قاعدة البيانات الحالية وعن أي مستخدمين مميزين (DBA، المطورين).توفر كل أنظمة RDBMS السائدة مرافق تدقيق لا يستطيع حتى DBA تعطيلها والتلاعب بالسرية.لذلك، يجب أن تكون إمكانية التدقيق المقدمة من قبل مورد RDBMS هي الخيار الأول.سيكون الخيار الآخر هو قارئ سجل المعاملات التابع لجهة خارجية أو قارئ السجل المخصص الذي يدفع المعلومات المتحللة إلى نظام المراسلة الذي ينتهي به الأمر في بعض أشكال مستودع بيانات التدقيق أو معالج الأحداث في الوقت الفعلي.في ملخص:يحتاج مهندس الحلول/"مهندس البيانات العملي" إلى المشاركة في تحديد مثل هذا النظام بناءً على المتطلبات.عادةً ما يكون الأمر خطيرًا للغاية بحيث لا يمكن تسليمه إلى المطورين للحصول على حل.

Answer 8

وفقا لمبدأ الانفصال:

1. يجب أن تكون جداول بيانات التدقيق منفصلة عن قاعدة البيانات الرئيسية.نظرًا لأن قواعد بيانات التدقيق يمكن أن تحتوي على الكثير من البيانات التاريخية، فمن المنطقي من وجهة نظر استخدام الذاكرة إبقائها منفصلة.

2. لا تستخدم المشغلات لتدقيق قاعدة البيانات بأكملها، لأنك ستنتهي في نهاية المطاف بفوضى من قواعد البيانات المختلفة التي تحتاج إلى دعمها.سيتعين عليك كتابة واحدة لـ DB2 وSQLServer وMysql وما إلى ذلك.

Answer 9

متأخرا إلى الحفلة، ولكنني أوصي بشدة مشروع التدقيق التلقائي.
إنه مجاني ومفتوح المصدر بنسبة 100%.تم تأليفه بواسطة SQL MVPs Paul Nielsen وJohn Sigouin.إنه مستقر جدًا وهو حاليًا في الإصدار 3.30.

بسيطة لتثبيت.فقط قم بتشغيل SP الذي يقدمونه.سيتم إنشاء مخطط التدقيق وبعض مقدمي خدمات الصيانة والمشغلات اللازمة للقيام بالتدقيق.ومن هناك، ما عليك سوى اختيار الجداول التي ترغب في تدقيقها وبأي تفاصيل.