database-design - مشاكل - مشكلة لا يمكن التعرف على تنسيق قاعدة البيانات




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

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

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

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

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

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

أي أفكار حول هذه الطريقة؟


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


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

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

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


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

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


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

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


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

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

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


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

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

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





database-design