استراتيجية فعالة لترك سجل التدقيق/سجل التغيير لتطبيقات قاعدة البيانات؟

Question

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

بعض المعلومات عن قاعدة البيانات:

• يحتاج إلى القدرة على النمو بآلاف السجلات أسبوعيًا
• 50-60 طاولة
• قد تحتوي الجداول المنقحة الرئيسية على عدة ملايين من السجلات لكل منها
• تم تعيين كمية معقولة من المفاتيح والفهارس الخارجية
• باستخدام PostgreSQL 8.x

Answer 1

لقد استخدمت في الماضي المشغلات لإنشاء تسجيل تحديث/إدراج/حذف قاعدة البيانات.

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

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

Answer 2

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

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

Answer 3

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

يهدف مشروع Envers إلى تمكين الإصدار السهل لفئات JPA المستمرة.كل ما عليك فعله هو إضافة تعليق توضيحي لفصلك المستمر أو بعض خصائصه، التي تريد إصدارها، باستخدام @Versioned.لكل كيان تم إصداره، سيتم إنشاء جدول، والذي سيحتفظ بسجل التغييرات التي تم إجراؤها على الكيان.يمكنك بعد ذلك استرداد البيانات التاريخية والاستعلام عنها دون بذل الكثير من الجهد.

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

Answer 4

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

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

Answer 5

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

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

Answer 6

أستخدم SQL Server، وليس PostgreSQL، لذلك لست متأكدًا مما إذا كان هذا سيعمل معك أم لا، ولكن كان لدى Pop Rivett مقالة رائعة حول إنشاء مسار تدقيق هنا:الأسئلة الشائعة رقم 5 الخاصة بـ Pop rivett's SQL Server:البوب ​​على درب التدقيق

قم بإنشاء جدول تدقيق، ثم قم بإنشاء مشغل لكل جدول تريد تدقيقه.

تَلمِيح:يستخدم كودسميث لبناء المشغلات الخاصة بك.