إدارة ترحيل تغييرات قاعدة البيانات المعطلة إلى قاعدة بيانات مشتركة بواسطة الإصدار القديم من نفس التطبيق

Question

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

كان أورين جيدًا بريد إعداد المشكلة، لكنها انتهت بـ:

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

لم يأتِ منشور المتابعة أبدًا ؛-).كيف يمكنك إدارة ترحيل تغييرات قاعدة البيانات المعطلة إلى قاعدة بيانات مشتركة بواسطة الإصدار القديم من نفس التطبيق.كيف يمكنك الحفاظ على مزامنة البيانات؟

Answer 1

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

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

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

Answer 2

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

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

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

في بعض الحالات، لا تحتاج إلى جدول جديد - قد تحتاج فقط إلى مشغلات.

Answer 3

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

ويمكنك الحفاظ على العقد المبرم بين التطبيقات القديمة والجديدة وراء وجهات النظر حول قمة جداول جديدة. استخدام قبل / بدلا من المشغلات للتعامل مع يكتب في وجهات النظر "القديمة" التي الكتابة فعلا في الجداول الجديدة.

وأنت الحفاظ على 2 إصدارات رمز ويجب أن يزال تطوير التطبيق القديم الخاص بك ولكن لا مفر منه.

وبهذه الطريقة، لا توجد مشاكل المزامنة وفعالية عليك أن تتعامل مع النزاعات النسخ المتماثل بين "القديمة" ومخططات "الجديدة".

وأكثر من 2 الإصدارات يصبح معقدا كما ذكر ...

Answer 4

بداية أود أن أقول إن هذه المشكلة صعبة للغاية وقد لا تجد لها إجابة كاملة.

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

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

لدينا في هذه اللحظة قاعدتان نحاول اتباعهما:

1. أولاً، هل أن الكود القديم (sql، procs المخزنة، الوظيفة، إلخ) يعمل كما هو ويجب الاحتفاظ به كما هو، دون تعديل أكثر من اللازم ما لم تكن هناك حالة (خطأ أو تغيير في الميزة)، وبالطبع، حاول توثيقه قدر الإمكان (خاصة المشاكل مثل:""وتف!، لماذا فعل ذلك بدلاً من ذلك؟").

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

نحاول أيضًا كتابة أكبر عدد ممكن من اختبارات الوحدات بشرط أن يعمل محللو الأعمال جنبًا إلى جنب ويوثقون قواعد العمل.

يعد إعادة هيكلة قاعدة البيانات مجالًا معقدًا للغاية يجب الإجابة عليه في إجابة قصيرة.هناك الكثير من الكتب التي تجيب على جميع مشاكلك، واحد http://databaserefactoring.com/ يتم الإشارة إليه في أحد إجابات.

التعديل لاحقًا:نأمل أن تجيب القاعدة الثانية أيضًا على التعامل مع التغييرات العاجلة.