كيف يمكنني استخدام مسار التدقيق لعرض الحقول التي تم تحريرها من قبل؟

Question

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

سيتم تطوير التطبيق بلغة PHP/MSSQL، وسيكون ذو حركة مرور منخفضة.

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

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

1. أن أكون قادرًا على رؤية سجل بجميع التغييرات التي تم إجراؤها على الحقل (أعرف تمامًا كيفية القيام بذلك)

2. كن قادرًا على رؤية مؤشر بجوار أي حقل في السجل تم تغييره (وربما معلومات أخرى مثل تاريخ آخر تغيير)، عند عرض سجل في التطبيق.

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

Answer 1

سأتعامل مع معلومات التدقيق بشكل منفصل عن معلومات المجال الفعلية قدر الإمكان.

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

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

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

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

تستخدم بعض تطبيقات Enterprisy الكبيرة التي أحتفظ بها البنية التالية تقريبًا:

• تغيير جدول الرأس المطابق لتغيير سجل في الجدول.

مجالات:

changeId, changeTable, changedPrimaryKey, userName, dateTime

- جدول تغيير الحقل الموافق للحقل الذي تم تغييره.

مجالات:

changeId, changeField, oldValue, NewValue

محتوى العينة:

تغيير الرأس:

'1', 'BooksTable', '1852860138', 'AdamsD', '2009-07-01 15:30'

تغيير العنصر:

'1', 'Title', 'The Hitchhiker's Guide to the Gaxaly', 'The Hitchhiker's Guide to the Galaxy'
'1', 'Author', 'Duglas Adasm', 'Douglas Adams'

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

Answer 2

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

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

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

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

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

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

Answer 3

شخصيًا، سأجعل التتبع بسيطًا، وإعداد التقارير غير تقليدي.

في كل مرة يقوم المستخدم بإدراج سجل، يمكنك إجراء إدراج في جدول التدقيق لهذا الجدول

'I', 'Date', 'User', 'Data column1','Data Column2', etc.

هذا على افتراض أن بنية الجداول لن تتغير بمرور الوقت (re.كمية أعمدة البيانات)

للحصول على التحديثات، فقط أدخل

'U', 'Date', 'User', 'Data column1', etc

أدخل ما أدخله المستخدم للتو كتحديث.

وبعد ذلك، بعد الإدراج والتحديث، سيكون لديك ما يلي

'I','May 3 2009','BLT','person005','John','Smith','Marketing'
'U','May 4 2009','BLT','person005','John','Smith','Accounting'

بعد ذلك، إنه مجرد تقرير سهل لإظهار أن سجل الشخص الفريد "person005" يحتوي على إدراج وتحديث، حيث تم تحديث القسم الخاص به.

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