ما هي أفضل طريقة لتخزين التغييرات في سجلات قاعدة البيانات التي تتطلب الموافقة قبل أن تكون مرئية؟

Question

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

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

هل هناك تجارب شخصية مع هذه الأساليب أو غيرها قد تكون جيدة؟

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

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

أي أفكار حول هذا الأسلوب؟

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

1. الجدول الرئيسي أ
2. جدول B آخر يخزن السجل الذي تم تغييره (وبالتالي فهو مشابه تمامًا للأول) + عمودين إضافيين (مفتاح FKey إلى C ورمز للإشارة إلى نوع التغيير)
3. جدول ثالث C يخزن كافة السجلات التي تحتاج إلى موافقة
4. الجدول الرابع D الذي يخزن التاريخ (ربما لا تحتاج إليه).

أوصي بهذا النهج.إنه يتعامل مع جميع السيناريوهات بما في ذلك التحديثات والحذف بأمان شديد.

Answer 4

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

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

Answer 5

سأقوم بإنشاء جدول بعلامة وإنشاء طريقة عرض مثل

 CREATE OR REPLACE VIEW AS 

  SELECT * FROM my_table where approved = 1

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

قد يكون لنقل السجلات بعض الاعتبارات المتعلقة بالأداء.لكن الجداول المقسمة يمكن أن تفعل شيئًا مشابهًا تمامًا.

Answer 6

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

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

Answer 7

فكرة أخرى هي أن يكون لديك ثلاثة طاولات.

• سيكون أحدهما هو الجدول الرئيسي للاحتفاظ بالبيانات الأصلية.
• والثاني يحمل البيانات المقترحة.
• والثالث سيحمل البيانات التاريخية.

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

Answer 8

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