قائمة مرجعية لترقيات مخطط قاعدة البيانات

Question

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

أنا أبحث عن قائمة مرجعية أو جدول زمني لعناصر العمل، مثل

• 8:30 إغلاق التطبيقات
• 8:45 تعديل المخطط
• 9:15 تثبيت تطبيقات جديدة
• 9:30 إعادة تشغيل ديسيبل

إلخ، موضحًا كيفية تقليل المخاطر ووقت التوقف عن العمل.قضايا مثل

• التراجع عن الترقية إذا ساءت الأمور
• تقليل التأثير على التطبيقات الحالية
• التحديثات "السريعة" أثناء تشغيل قاعدة البيانات
• الترويج من التطوير إلى الاختبار إلى خوادم الإنتاج

هي ذات أهمية خاصة.

Answer 1

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

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

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

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

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

إذن هذا إجمالي 4 قواعد بيانات:

1. المطور:يجب إجراء كافة التغييرات في البرنامج النصي للتغيير، وليس مع الاستوديو أبدًا.
2. امتحان:اختبار التكامل يحدث هنا
3. نسخة من الإنتاج:ممارسة النشر في اللحظة الأخيرة
4. إنتاج

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

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

Answer 2

أعتقد أنك قد نظرت في قراءات سكوت أمبلر؟http://www.agiledata.org/essays/databaseRefactoring.html

Answer 3

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

إن الطريقة الحالية التي نتبعها بها عيوب واضحة، وأنا منفتح على اقتراحات أخرى.

1. احصل على تفريغ مخطط يحتوي على بيانات ثابتة مطلوبة لتحديثها والتحكم في الإصدار.
2. في كل مرة تقوم فيها بإجراء تغيير المخطط، ALTER، CREATE، وما إلى ذلك.تفريغه إلى ملف ورميه في التحكم في الإصدار.
3. تأكد من تحديث تفريغ SQL db الأصلي.
4. عند إجراء عمليات الدفع للبث المباشر، تأكد من قيامك أنت أو البرنامج النصي الخاص بك بتطبيق ملفات SQL على قاعدة البيانات.
5. قم بتنظيف ملفات SQL القديمة الموجودة في التحكم في الإصدار عندما تصبح قديمة.

هذا ليس الأمثل بأي حال من الأحوال وليس المقصود منه أن يكون قاعدة بيانات "احتياطية".إنه ببساطة حث على العيش بسهولة، وإبقاء المطورين على نفس الصفحة.من المحتمل أن يكون هناك شيء رائع يمكنك إعداده باستخدام capistrano فيما يتعلق بأتمتة تطبيق ملفات SQL على قاعدة البيانات.

سيكون التحكم في الإصدار الخاص بـ Db رائعًا جدًا.من المحتمل أن يكون هناك شيء يفعل ذلك، وإذا لم يكن هناك فمن المحتمل أن يكون هناك.

Answer 4

وإذا كانت ورقة سكوت أمبلر تثير شهيتك، فيمكنني أن أوصي بكتابه مع برامود جي سادولاج بعنوان "قواعد بيانات إعادة البناء" - http://www.ambysoft.com/books/refactoringDatabases.html

يوجد أيضًا الكثير من النصائح والمعلومات المفيدة في مجموعة Agile Database في Yahoo - http://tech.groups.yahoo.com/group/agileDatabases/

Answer 5

ملاحظتان سريعتان:

1. غني عن القول...لذلك سأقول ذلك مرتين.
   تأكد من أن لديك نسخة احتياطية صالحة.
   تأكد من أن لديك نسخة احتياطية صالحة.

2. @مك.الدفع مشاركة مدونة جيف على التحكم في إصدار قاعدة البيانات (إذا لم تكن قد قمت بذلك بالفعل)